You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Benson Margulies <bi...@gmail.com> on 2015/07/14 17:15:02 UTC
Intend to release maven-assembly-plugin 3.0.0
I have selfish/professional reasons to desire a release with a fix to
MASSEMBLY-777, and the fix, involving an intentional incompatibility,
needs to be 3.0.0, and, anyhow, the pom is all set up for 3.0.0 to be
next. So I plan to start the process tomorrow morning EDT unless
someone objects.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Intend to release maven-assembly-plugin 3.0.0
Posted by Kristian Rosenvold <kr...@gmail.com>.
We were discussing which version to use for core dependencies. Assembly
plugin will not be 3.0 unless you do it yourself.
Kristian
2015-07-16 22:18 GMT+02:00 Robert Scholte <rf...@apache.org>:
> The reason why you're not sure of the exact version explains why we ended
> up with simply 3.0 :)
> Now it is clear for everybody.
>
> Robert
>
> Op Wed, 15 Jul 2015 08:43:59 +0200 schreef Kristian Rosenvold <
> kristian.rosenvold@zenior.no>:
>
>
> 14. jul. 2015 21.04 skrev "Robert Scholte" <rfscholte@apache.org
>>
>>> mvn clean verify -Prun-its -Dinvoker.mavenHome=d:\apache-maven-3.0 fails
>>>
>> on my machine
>>
>>>
>>> We are 3.0.3/4/5 minimum, which I believe is in accordance with our
>> discussions. Cant remember exactly which versjon though :)
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Intend to release maven-assembly-plugin 3.0.0
Posted by Stephen Connolly <st...@gmail.com>.
[joke]
If you're really stuck I can invoke a claim that we agreed X and we can
rely on everyone else being too lazy to find the counter-evidence on the
mailing list archives!
[/joke]
More seriously, I remember a discussion but my memory fails me on the exact
version we settled on... Anything less than 3.0.3 *for users* is a bad
thing IMHO. I don't think there are much API difference between the 3.0.x
series to make a critical difference though
On Thursday, July 16, 2015, Robert Scholte <rf...@apache.org> wrote:
> The reason why you're not sure of the exact version explains why we ended
> up with simply 3.0 :)
> Now it is clear for everybody.
>
> Robert
>
> Op Wed, 15 Jul 2015 08:43:59 +0200 schreef Kristian Rosenvold <
> kristian.rosenvold@zenior.no>:
>
> 14. jul. 2015 21.04 skrev "Robert Scholte" <rfscholte@apache.org
>>
>>> mvn clean verify -Prun-its -Dinvoker.mavenHome=d:\apache-maven-3.0 fails
>>>
>> on my machine
>>
>>>
>>> We are 3.0.3/4/5 minimum, which I believe is in accordance with our
>> discussions. Cant remember exactly which versjon though :)
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Sent from my phone
Re: Intend to release maven-assembly-plugin 3.0.0
Posted by Robert Scholte <rf...@apache.org>.
The reason why you're not sure of the exact version explains why we ended
up with simply 3.0 :)
Now it is clear for everybody.
Robert
Op Wed, 15 Jul 2015 08:43:59 +0200 schreef Kristian Rosenvold
<kr...@zenior.no>:
> 14. jul. 2015 21.04 skrev "Robert Scholte" <rfscholte@apache.org
>> mvn clean verify -Prun-its -Dinvoker.mavenHome=d:\apache-maven-3.0 fails
> on my machine
>>
> We are 3.0.3/4/5 minimum, which I believe is in accordance with our
> discussions. Cant remember exactly which versjon though :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Intend to release maven-assembly-plugin 3.0.0
Posted by Kristian Rosenvold <kr...@zenior.no>.
14. jul. 2015 21.04 skrev "Robert Scholte" <rfscholte@apache.org
> mvn clean verify -Prun-its -Dinvoker.mavenHome=d:\apache-maven-3.0 fails
on my machine
>
We are 3.0.3/4/5 minimum, which I believe is in accordance with our
discussions. Cant remember exactly which versjon though :)
Re: Intend to release maven-assembly-plugin 3.0.0
Posted by Benson Margulies <bi...@gmail.com>.
I want to point out that the original set of changes here was a
complete violation of the principles Jason raised in the first place.
It was a completely breaking change, introduced incompatibly. Anyone
who had been pushing foo.filtered files around before it was out of
luck afterwards.
On Tue, Jul 14, 2015 at 3:58 PM, Robert Scholte <rf...@apache.org> wrote:
> I'd say as much as possible. I'm completely aware that not all can be
> removed, but a move from 2.x ot 3.x is THE moment to do these kind of
> changes. If you take a look at the Mojo's, most of them are already that
> much refactored that they are kind of empty classes, extending the same
> AbstractMojo.
> The fun starts probably with the ITs depending on deprecated goals, but
> "single" describes it is the ultimate goal replacing all others. With a bit
> of luck it's not that hard to fix.
> I would really take this opportunity to do these kind of things with this
> 3.0 release.
>
> Robert
>
> ps The o.a.m.plugins was a type, I meant o.a.m.plugin (all empty folders...)
>
> Op Tue, 14 Jul 2015 21:44:12 +0200 schreef Kristian Rosenvold
> <kr...@gmail.com>:
>
>
>> If point 5.3 is to be interpreted to mean "any" deprecations it officially
>> has my minus one, since it's simply not going to happen and it is a silly
>> requirement. We're using 3.0.0 to move maven version,not to settle a new
>> continent with lots of natives we can oppress.
>>
>> 5.3 is not a code change, so I cant veto it. But it's as silly as it gets.
>>
>>
>> I thought o.a.m.plugins was /supposed/ to be there, at least that's what I
>> renamed everything to ?
>>
>> Kristian
>>
>>
>> 2015-07-14 21:03 GMT+02:00 Robert Scholte <rf...@apache.org>:
>>
>>> Op Tue, 14 Jul 2015 20:46:50 +0200 schreef Kristian Rosenvold <
>>> kristian.rosenvold@gmail.com>:
>>>
>>>
>>> 2015-07-14 20:06 GMT+02:00 Robert Scholte <rf...@apache.org>:
>>>>
>>>>
>>>> Hi Benson,
>>>>>
>>>>>
>>>>> this is not the 3.0 version of a plugin I had in mind. For instance, it
>>>>> isn't compatible with all Maven3 versions and there's still a lot of
>>>>> cleanup to do[1]
>>>>>
>>>>>
>>>> It's compatible with all 3.x versions, but I did this before your shared
>>>> code had any features related to this. I also believe it has most of the
>>>> cleanup done. Did you have anything particular in mind ?
>>>>
>>>> Kristian
>>>>
>>>
>>> Hi Kristian,
>>>
>>> just the first things that comes to my mind:
>>> Scan the code for "deprecated", start by removing the deprecated mojo's:
>>> single (and the generated help) are the only valid goals.
>>>
>>> mvn clean verify -Prun-its -Dinvoker.mavenHome=d:\apache-maven-3.0 fails
>>> on my machine
>>>
>>> any reason why the o.a.m.plugins is still there?
>>>
>>> thanks,
>>> Robert
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Intend to release maven-assembly-plugin 3.0.0
Posted by Kristian Rosenvold <kr...@gmail.com>.
Well I suppose you're right.
The wiki document does not represent formal project policy anyway.
Kristian
2015-07-14 21:58 GMT+02:00 Robert Scholte <rf...@apache.org>:
> I'd say as much as possible. I'm completely aware that not all can be
> removed, but a move from 2.x ot 3.x is THE moment to do these kind of
> changes. If you take a look at the Mojo's, most of them are already that
> much refactored that they are kind of empty classes, extending the same
> AbstractMojo.
> The fun starts probably with the ITs depending on deprecated goals, but
> "single" describes it is the ultimate goal replacing all others. With a bit
> of luck it's not that hard to fix.
> I would really take this opportunity to do these kind of things with this
> 3.0 release.
>
> Robert
>
> ps The o.a.m.plugins was a type, I meant o.a.m.plugin (all empty
> folders...)
>
> Op Tue, 14 Jul 2015 21:44:12 +0200 schreef Kristian Rosenvold <
> kristian.rosenvold@gmail.com>:
>
>
> If point 5.3 is to be interpreted to mean "any" deprecations it officially
>> has my minus one, since it's simply not going to happen and it is a silly
>> requirement. We're using 3.0.0 to move maven version,not to settle a new
>> continent with lots of natives we can oppress.
>>
>> 5.3 is not a code change, so I cant veto it. But it's as silly as it gets.
>>
>>
>> I thought o.a.m.plugins was /supposed/ to be there, at least that's what I
>> renamed everything to ?
>>
>> Kristian
>>
>>
>> 2015-07-14 21:03 GMT+02:00 Robert Scholte <rf...@apache.org>:
>>
>> Op Tue, 14 Jul 2015 20:46:50 +0200 schreef Kristian Rosenvold <
>>> kristian.rosenvold@gmail.com>:
>>>
>>>
>>> 2015-07-14 20:06 GMT+02:00 Robert Scholte <rf...@apache.org>:
>>>
>>>>
>>>> Hi Benson,
>>>>
>>>>>
>>>>> this is not the 3.0 version of a plugin I had in mind. For instance, it
>>>>> isn't compatible with all Maven3 versions and there's still a lot of
>>>>> cleanup to do[1]
>>>>>
>>>>>
>>>>> It's compatible with all 3.x versions, but I did this before your
>>>> shared
>>>> code had any features related to this. I also believe it has most of the
>>>> cleanup done. Did you have anything particular in mind ?
>>>>
>>>> Kristian
>>>>
>>>>
>>> Hi Kristian,
>>>
>>> just the first things that comes to my mind:
>>> Scan the code for "deprecated", start by removing the deprecated mojo's:
>>> single (and the generated help) are the only valid goals.
>>>
>>> mvn clean verify -Prun-its -Dinvoker.mavenHome=d:\apache-maven-3.0 fails
>>> on my machine
>>>
>>> any reason why the o.a.m.plugins is still there?
>>>
>>> thanks,
>>> Robert
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Intend to release maven-assembly-plugin 3.0.0
Posted by Robert Scholte <rf...@apache.org>.
I'd say as much as possible. I'm completely aware that not all can be
removed, but a move from 2.x ot 3.x is THE moment to do these kind of
changes. If you take a look at the Mojo's, most of them are already that
much refactored that they are kind of empty classes, extending the same
AbstractMojo.
The fun starts probably with the ITs depending on deprecated goals, but
"single" describes it is the ultimate goal replacing all others. With a
bit of luck it's not that hard to fix.
I would really take this opportunity to do these kind of things with this
3.0 release.
Robert
ps The o.a.m.plugins was a type, I meant o.a.m.plugin (all empty
folders...)
Op Tue, 14 Jul 2015 21:44:12 +0200 schreef Kristian Rosenvold
<kr...@gmail.com>:
> If point 5.3 is to be interpreted to mean "any" deprecations it
> officially
> has my minus one, since it's simply not going to happen and it is a silly
> requirement. We're using 3.0.0 to move maven version,not to settle a new
> continent with lots of natives we can oppress.
>
> 5.3 is not a code change, so I cant veto it. But it's as silly as it
> gets.
>
>
> I thought o.a.m.plugins was /supposed/ to be there, at least that's what
> I
> renamed everything to ?
>
> Kristian
>
>
> 2015-07-14 21:03 GMT+02:00 Robert Scholte <rf...@apache.org>:
>
>> Op Tue, 14 Jul 2015 20:46:50 +0200 schreef Kristian Rosenvold <
>> kristian.rosenvold@gmail.com>:
>>
>>
>> 2015-07-14 20:06 GMT+02:00 Robert Scholte <rf...@apache.org>:
>>>
>>> Hi Benson,
>>>>
>>>> this is not the 3.0 version of a plugin I had in mind. For instance,
>>>> it
>>>> isn't compatible with all Maven3 versions and there's still a lot of
>>>> cleanup to do[1]
>>>>
>>>>
>>> It's compatible with all 3.x versions, but I did this before your
>>> shared
>>> code had any features related to this. I also believe it has most of
>>> the
>>> cleanup done. Did you have anything particular in mind ?
>>>
>>> Kristian
>>>
>>
>> Hi Kristian,
>>
>> just the first things that comes to my mind:
>> Scan the code for "deprecated", start by removing the deprecated mojo's:
>> single (and the generated help) are the only valid goals.
>>
>> mvn clean verify -Prun-its -Dinvoker.mavenHome=d:\apache-maven-3.0 fails
>> on my machine
>>
>> any reason why the o.a.m.plugins is still there?
>>
>> thanks,
>> Robert
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Intend to release maven-assembly-plugin 3.0.0
Posted by Kristian Rosenvold <kr...@gmail.com>.
If point 5.3 is to be interpreted to mean "any" deprecations it officially
has my minus one, since it's simply not going to happen and it is a silly
requirement. We're using 3.0.0 to move maven version,not to settle a new
continent with lots of natives we can oppress.
5.3 is not a code change, so I cant veto it. But it's as silly as it gets.
I thought o.a.m.plugins was /supposed/ to be there, at least that's what I
renamed everything to ?
Kristian
2015-07-14 21:03 GMT+02:00 Robert Scholte <rf...@apache.org>:
> Op Tue, 14 Jul 2015 20:46:50 +0200 schreef Kristian Rosenvold <
> kristian.rosenvold@gmail.com>:
>
>
> 2015-07-14 20:06 GMT+02:00 Robert Scholte <rf...@apache.org>:
>>
>> Hi Benson,
>>>
>>> this is not the 3.0 version of a plugin I had in mind. For instance, it
>>> isn't compatible with all Maven3 versions and there's still a lot of
>>> cleanup to do[1]
>>>
>>>
>> It's compatible with all 3.x versions, but I did this before your shared
>> code had any features related to this. I also believe it has most of the
>> cleanup done. Did you have anything particular in mind ?
>>
>> Kristian
>>
>
> Hi Kristian,
>
> just the first things that comes to my mind:
> Scan the code for "deprecated", start by removing the deprecated mojo's:
> single (and the generated help) are the only valid goals.
>
> mvn clean verify -Prun-its -Dinvoker.mavenHome=d:\apache-maven-3.0 fails
> on my machine
>
> any reason why the o.a.m.plugins is still there?
>
> thanks,
> Robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Intend to release maven-assembly-plugin 3.0.0
Posted by Robert Scholte <rf...@apache.org>.
Op Tue, 14 Jul 2015 20:46:50 +0200 schreef Kristian Rosenvold
<kr...@gmail.com>:
> 2015-07-14 20:06 GMT+02:00 Robert Scholte <rf...@apache.org>:
>
>> Hi Benson,
>>
>> this is not the 3.0 version of a plugin I had in mind. For instance, it
>> isn't compatible with all Maven3 versions and there's still a lot of
>> cleanup to do[1]
>>
>
> It's compatible with all 3.x versions, but I did this before your shared
> code had any features related to this. I also believe it has most of the
> cleanup done. Did you have anything particular in mind ?
>
> Kristian
Hi Kristian,
just the first things that comes to my mind:
Scan the code for "deprecated", start by removing the deprecated mojo's:
single (and the generated help) are the only valid goals.
mvn clean verify -Prun-its -Dinvoker.mavenHome=d:\apache-maven-3.0 fails
on my machine
any reason why the o.a.m.plugins is still there?
thanks,
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Intend to release maven-assembly-plugin 3.0.0
Posted by Kristian Rosenvold <kr...@gmail.com>.
2015-07-14 20:06 GMT+02:00 Robert Scholte <rf...@apache.org>:
> Hi Benson,
>
> this is not the 3.0 version of a plugin I had in mind. For instance, it
> isn't compatible with all Maven3 versions and there's still a lot of
> cleanup to do[1]
>
It's compatible with all 3.x versions, but I did this before your shared
code had any features related to this. I also believe it has most of the
cleanup done. Did you have anything particular in mind ?
Kristian
Re: Intend to release maven-assembly-plugin 3.0.0
Posted by Robert Scholte <rf...@apache.org>.
Hi Benson,
this is not the 3.0 version of a plugin I had in mind. For instance, it
isn't compatible with all Maven3 versions and there's still a lot of
cleanup to do[1]
Other messages are clear was well, especially from Hervé about trying to
figure out why these extensions are special.
thanks,
Robert
[1]
https://cwiki.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies
*
Op Tue, 14 Jul 2015 17:15:02 +0200 schreef Benson Margulies
<bi...@gmail.com>:
> I have selfish/professional reasons to desire a release with a fix to
> MASSEMBLY-777, and the fix, involving an intentional incompatibility,
> needs to be 3.0.0, and, anyhow, the pom is all set up for 3.0.0 to be
> next. So I plan to start the process tomorrow morning EDT unless
> someone objects.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Intend to release maven-assembly-plugin 3.0.0
Posted by Kristian Rosenvold <kr...@zenior.no>.
I also only have 4 failing ITs to fix wrt removing the deprecated goals.
One heck of a job though...
K
18. jul. 2015 1.33 a.m. skrev "Hervé BOUTEMY" <he...@free.fr>:
> after investigation (everything is described in details in MASSEMBLY-777),
> these exclusions were necessary when using File based filtering, creating
> temporary files with extensions
>
> but Kristian fixed the filtering by switching from File based filtering to
> Reader
> based filtering for maven-assembly-plugin 2.5.1
>
> Thank you Kristian :)
>
> I then removed the exclusions without any fear: now unused hack
>
> Regards,
>
> Hervé
>
> Le mardi 14 juillet 2015 18:11:59 Sander Verhagen a écrit :
> > Interesting, the commit for "**/*.filtered" says: "Based on patch
> > provided...". But the patch does NOT exclude the .filtered, while the
> > commit does. That makes it a very unclear whether the .filtered was
> > actually so much related to MASSEMBLY-154. The unit test (change) does
> also
> > not address this detail of the code change. I could see how this is all
> > *so* sketchy that you'd just want to get rid of it. If you choose to keep
> > it, you could change it from an undocumented feature into a documented
> > feature, easy enough, though :)
>
> >
> >
> > Sander Verhagen
> > [ sander@sanderverhagen.net ]
> >
> > NOTICE: my e-mail address has changed. Please remove Verhagen@Sander.com
> now
> > and start using Sander@SanderVerhagen.net from now on. Please update
> your
> > address book. Thank you!
>
> >
> >
> > > -----Original Message-----
> > > From: Hervé BOUTEMY [mailto:herve.boutemy@free.fr]
> > > Sent: Tuesday, July 14, 2015 10:53
> > > To: Maven Developers List
> > > Subject: Re: Intend to release maven-assembly-plugin 3.0.0
> > >
> > > blame done and found the inital commit for the 2 excludes:
> > > see https://issues.apache.org/jira/browse/MASSEMBLY-777
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le mardi 14 juillet 2015 17:19:30 Sander Verhagen a écrit :
> > >
> > > > I'm not much of a stakeholder in this but after following the
> > > > discussion I'm getting curious if there's any hints to why this was
> > > > introduced? Is there a VCS "blame" to do that links to a JIRA issue
> of
> > > > some kind? This could uncover at least a few (reasonable or not) use
> > > > cases for this (admitted, seemingly strange) micro-behavior.
> > >
> > >
> > >
> > > >
> > > >
> > > >
> > > > Sander Verhagen
> > > > [ sander@sanderverhagen.net ]
> > > >
> > > >
> > > >
> > > > NOTICE: my e-mail address has changed. Please remove
> > > > Verhagen@Sander.com now and start using Sander@SanderVerhagen.net
> > >
> > > from
> > >
> > > > now on. Please update your address book. Thank you!
> > >
> > >
> > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Benson Margulies [mailto:bimargulies@gmail.com]
> > > > > Sent: Tuesday, July 14, 2015 10:05
> > > > > To: Maven Developers List
> > > > > Subject: Re: Intend to release maven-assembly-plugin 3.0.0
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > If it’s easy to make compatible why would you not do it?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Really, this is the only interesting point of disagreement here.
> > > > > It's easy for
> > >
> > > _me_ to make it compatible. It's hard for readers of the assembly
> > >
> > > > > descriptor documentation to digest and understand yet another
> option
> > > > > that tweaks yet another micro-behavior. One user out of 10,000
> might
> > > > > be disturbed by the arrival of a foo.filtered file. 9,999 users out
> > > > > of
> > > > > 10,000 will have to wade through the extra doc. And some unknown
> > > > > number of people will run into the (to me) bizarre current
> behavior.
> > > > >
> > > > >
> > > > >
> > > > >
> --------------------------------------------------------------------
> > > > > - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> > > > > additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > > >
> > > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
Re: Intend to release maven-assembly-plugin 3.0.0
Posted by Hervé BOUTEMY <he...@free.fr>.
after investigation (everything is described in details in MASSEMBLY-777),
these exclusions were necessary when using File based filtering, creating
temporary files with extensions
but Kristian fixed the filtering by switching from File based filtering to Reader
based filtering for maven-assembly-plugin 2.5.1
Thank you Kristian :)
I then removed the exclusions without any fear: now unused hack
Regards,
Hervé
Le mardi 14 juillet 2015 18:11:59 Sander Verhagen a écrit :
> Interesting, the commit for "**/*.filtered" says: "Based on patch
> provided...". But the patch does NOT exclude the .filtered, while the
> commit does. That makes it a very unclear whether the .filtered was
> actually so much related to MASSEMBLY-154. The unit test (change) does also
> not address this detail of the code change. I could see how this is all
> *so* sketchy that you'd just want to get rid of it. If you choose to keep
> it, you could change it from an undocumented feature into a documented
> feature, easy enough, though :)
>
>
> Sander Verhagen
> [ sander@sanderverhagen.net ]
>
> NOTICE: my e-mail address has changed. Please remove Verhagen@Sander.com now
> and start using Sander@SanderVerhagen.net from now on. Please update your
> address book. Thank you!
>
>
> > -----Original Message-----
> > From: Hervé BOUTEMY [mailto:herve.boutemy@free.fr]
> > Sent: Tuesday, July 14, 2015 10:53
> > To: Maven Developers List
> > Subject: Re: Intend to release maven-assembly-plugin 3.0.0
> >
> > blame done and found the inital commit for the 2 excludes:
> > see https://issues.apache.org/jira/browse/MASSEMBLY-777
> >
> > Regards,
> >
> > Hervé
> >
> > Le mardi 14 juillet 2015 17:19:30 Sander Verhagen a écrit :
> >
> > > I'm not much of a stakeholder in this but after following the
> > > discussion I'm getting curious if there's any hints to why this was
> > > introduced? Is there a VCS "blame" to do that links to a JIRA issue of
> > > some kind? This could uncover at least a few (reasonable or not) use
> > > cases for this (admitted, seemingly strange) micro-behavior.
> >
> >
> >
> > >
> > >
> > >
> > > Sander Verhagen
> > > [ sander@sanderverhagen.net ]
> > >
> > >
> > >
> > > NOTICE: my e-mail address has changed. Please remove
> > > Verhagen@Sander.com now and start using Sander@SanderVerhagen.net
> >
> > from
> >
> > > now on. Please update your address book. Thank you!
> >
> >
> >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Benson Margulies [mailto:bimargulies@gmail.com]
> > > > Sent: Tuesday, July 14, 2015 10:05
> > > > To: Maven Developers List
> > > > Subject: Re: Intend to release maven-assembly-plugin 3.0.0
> > > >
> > > >
> > > >
> > > >
> > > > > If it’s easy to make compatible why would you not do it?
> > > >
> > > >
> > > >
> > > >
> > > > Really, this is the only interesting point of disagreement here.
> > > > It's easy for
> >
> > _me_ to make it compatible. It's hard for readers of the assembly
> >
> > > > descriptor documentation to digest and understand yet another option
> > > > that tweaks yet another micro-behavior. One user out of 10,000 might
> > > > be disturbed by the arrival of a foo.filtered file. 9,999 users out
> > > > of
> > > > 10,000 will have to wade through the extra doc. And some unknown
> > > > number of people will run into the (to me) bizarre current behavior.
> > > >
> > > >
> > > >
> > > > --------------------------------------------------------------------
> > > > - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> > > > additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> > >
> > >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
RE: Intend to release maven-assembly-plugin 3.0.0
Posted by Sander Verhagen <sa...@sanderverhagen.net>.
Interesting, the commit for "**/*.filtered" says: "Based on patch provided...". But the patch does NOT exclude the .filtered, while the commit does. That makes it a very unclear whether the .filtered was actually so much related to MASSEMBLY-154. The unit test (change) does also not address this detail of the code change. I could see how this is all *so* sketchy that you'd just want to get rid of it. If you choose to keep it, you could change it from an undocumented feature into a documented feature, easy enough, though :)
Sander Verhagen
[ sander@sanderverhagen.net ]
NOTICE: my e-mail address has changed. Please remove Verhagen@Sander.com now and start using Sander@SanderVerhagen.net from now on. Please update your address book. Thank you!
> -----Original Message-----
> From: Hervé BOUTEMY [mailto:herve.boutemy@free.fr]
> Sent: Tuesday, July 14, 2015 10:53
> To: Maven Developers List
> Subject: Re: Intend to release maven-assembly-plugin 3.0.0
>
> blame done and found the inital commit for the 2 excludes:
> see https://issues.apache.org/jira/browse/MASSEMBLY-777
>
> Regards,
>
> Hervé
>
> Le mardi 14 juillet 2015 17:19:30 Sander Verhagen a écrit :
> > I'm not much of a stakeholder in this but after following the
> > discussion I'm getting curious if there's any hints to why this was
> > introduced? Is there a VCS "blame" to do that links to a JIRA issue of
> > some kind? This could uncover at least a few (reasonable or not) use
> > cases for this (admitted, seemingly strange) micro-behavior.
>
> >
> >
> > Sander Verhagen
> > [ sander@sanderverhagen.net ]
> >
> > NOTICE: my e-mail address has changed. Please remove
> > Verhagen@Sander.com now and start using Sander@SanderVerhagen.net
> from
> > now on. Please update your address book. Thank you!
>
> >
> > > -----Original Message-----
> > > From: Benson Margulies [mailto:bimargulies@gmail.com]
> > > Sent: Tuesday, July 14, 2015 10:05
> > > To: Maven Developers List
> > > Subject: Re: Intend to release maven-assembly-plugin 3.0.0
> > >
> > >
> > > > If it’s easy to make compatible why would you not do it?
> > >
> > >
> > > Really, this is the only interesting point of disagreement here.
> > > It's easy for
> _me_ to make it compatible. It's hard for readers of the assembly
> > > descriptor documentation to digest and understand yet another option
> > > that tweaks yet another micro-behavior. One user out of 10,000 might
> > > be disturbed by the arrival of a foo.filtered file. 9,999 users out
> > > of
> > > 10,000 will have to wade through the extra doc. And some unknown
> > > number of people will run into the (to me) bizarre current behavior.
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> > > additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
Re: Intend to release maven-assembly-plugin 3.0.0
Posted by Hervé BOUTEMY <he...@free.fr>.
blame done and found the inital commit for the 2 excludes:
see https://issues.apache.org/jira/browse/MASSEMBLY-777
Regards,
Hervé
Le mardi 14 juillet 2015 17:19:30 Sander Verhagen a écrit :
> I'm not much of a stakeholder in this but after following the discussion I'm
> getting curious if there's any hints to why this was introduced? Is there a
> VCS "blame" to do that links to a JIRA issue of some kind? This could
> uncover at least a few (reasonable or not) use cases for this (admitted,
> seemingly strange) micro-behavior.
>
>
> Sander Verhagen
> [ sander@sanderverhagen.net ]
>
> NOTICE: my e-mail address has changed. Please remove Verhagen@Sander.com now
> and start using Sander@SanderVerhagen.net from now on. Please update your
> address book. Thank you!
>
> > -----Original Message-----
> > From: Benson Margulies [mailto:bimargulies@gmail.com]
> > Sent: Tuesday, July 14, 2015 10:05
> > To: Maven Developers List
> > Subject: Re: Intend to release maven-assembly-plugin 3.0.0
> >
> >
> > > If it’s easy to make compatible why would you not do it?
> >
> >
> > Really, this is the only interesting point of disagreement here. It's easy
> > for
_me_ to make it compatible. It's hard for readers of the assembly
> > descriptor documentation to digest and understand yet another option that
> > tweaks yet another micro-behavior. One user out of 10,000 might be
> > disturbed by the arrival of a foo.filtered file. 9,999 users out of
> > 10,000 will have to wade through the extra doc. And some unknown number
> > of people will run into the (to me) bizarre current behavior.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional
> > commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Intend to release maven-assembly-plugin 3.0.0
Posted by Sander Verhagen <sa...@sanderverhagen.net>.
I'm not much of a stakeholder in this but after following the discussion I'm getting curious if there's any hints to why this was introduced? Is there a VCS "blame" to do that links to a JIRA issue of some kind? This could uncover at least a few (reasonable or not) use cases for this (admitted, seemingly strange) micro-behavior.
Sander Verhagen
[ sander@sanderverhagen.net ]
NOTICE: my e-mail address has changed. Please remove Verhagen@Sander.com now and start using Sander@SanderVerhagen.net from now on. Please update your address book. Thank you!
> -----Original Message-----
> From: Benson Margulies [mailto:bimargulies@gmail.com]
> Sent: Tuesday, July 14, 2015 10:05
> To: Maven Developers List
> Subject: Re: Intend to release maven-assembly-plugin 3.0.0
>
> > If it’s easy to make compatible why would you not do it?
>
> Really, this is the only interesting point of disagreement here. It's easy for
> _me_ to make it compatible. It's hard for readers of the assembly descriptor
> documentation to digest and understand yet another option that tweaks yet
> another micro-behavior. One user out of 10,000 might be disturbed by the
> arrival of a foo.filtered file. 9,999 users out of 10,000 will have to wade
> through the extra doc. And some unknown number of people will run into
> the (to me) bizarre current behavior.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional
> commands, e-mail: dev-help@maven.apache.org
Re: Intend to release maven-assembly-plugin 3.0.0
Posted by Benson Margulies <bi...@gmail.com>.
> If it’s easy to make compatible why would you not do it?
Really, this is the only interesting point of disagreement here. It's
easy for _me_ to make it compatible. It's hard for readers of the
assembly descriptor documentation to digest and understand yet another
option that tweaks yet another micro-behavior. One user out of 10,000
might be disturbed by the arrival of a foo.filtered file. 9,999 users
out of 10,000 will have to wade through the extra doc. And some
unknown number of people will run into the (to me) bizarre current
behavior.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Intend to release maven-assembly-plugin 3.0.0
Posted by Jason van Zyl <ja...@takari.io>.
> On Jul 14, 2015, at 11:59 AM, Benson Margulies <bi...@gmail.com> wrote:
>
> On Tue, Jul 14, 2015 at 11:48 AM, Jason van Zyl <ja...@takari.io> wrote:
>> Ultimately your call. If users can upgrade and existing configuration will work there’s no issue. If it breaks the user simply upgrading for something you need need for expediency not so much. If it’s the first case there’s no issue, if it’s the second then I would take the 15 minutes to make it backward compatible and therefore a non-issue then it’s win-win. I have no issue with any committer punching in fixes, even for self-interested reasons, but personally I try my best to make it transparent over upgrades.
>
> Jason, thank you. I completely agree about transparency in general. It
> seems to me that this hinges on the definition of 'works'. Does adding
> an unwanted file to the output constitute 'not working’?
User upgrades and it doesn’t work I consider not working. Maven plugins are different than libraries and unless you are adding major feature changes it doesn’t warrant a signal to a user that all is going to break. Especially in this where it can be avoided. People who run the build are often not the people who setup the build and that person is often not around so making breaking changes to configurations on teams is super disruptive.
> I could
> imagine arguments in both directions. The other consideration here, in
> my head, is that there's a cost to an ever-growing list of obscure
> options in the assembly descriptor, and that a major version boundary,
> teed up for other good reasons, is an opportunity to clean house.
Yes, but that is unlikely to happen. I highly doubt your change is going to trigger a wholesale cleanup of one of the most complicated plugins we have. And even if it was done it should still be done iteratively for something like the assembly plugin. People who look forward to a super new assembly plugin where they have to fiddle with their configuration to make it work are in the vast minority. It’s the configuration of the plugin which is the most important and the way Maven plugin configuration works it’s pretty much possible 100% of the time to preserve a pre-existing model. You can make wholesale changes, preserve the model, keep existing users happy and allow new users to consciously make the choice to change their configuration to take advantage of new features. That’s really the only sensible path we have for most of our plugins. The onus is on us to make things work for as long as humanly possible. That’s the nature of build infrastructure.
> I
> considered, even, sending email proposing to remove the
> long-deprecated goals from this plugin.
>
Again, I think the vast majority of people don’t really look at these. If the build works they carry on, that’s just the nature of the behaviour of most Maven users. In developing applications I’m somewhat different but for build infrastructure I tend to ignore my indignation and “unclean” code and the inelegance of some of our systems. We live with our baggage and if you want to improve it, it certainly can be done but it just has to be done with care. Your example here for a major change just seems unwarranted.
> For now, I've decided to hold off a day or two and see what other
> people think; I have a local workaround. And for the record, this
> isn't 'my client', this is me doing my day job using Maven where I ran
> into this.
>
If it’s easy to make compatible why would you not do it?
>
>
>>
>>> On Jul 14, 2015, at 11:36 AM, Benson Margulies <bi...@gmail.com> wrote:
>>>
>>> Jason, I don't think that this constitutes a punch in the face of
>>> anyone for any purpose.
>>>
>>> Did you actually read the JIRA? I've removed a file exclusion from
>>> file sets. So, if someone was depending on the undocumented fact that
>>> the assembly plugin would refuse to copy a file named (e.g.)
>>> lexicon.filtered, they will now find this file in their output, if and
>>> only if they upgrade to 3.0.0; and then, if they don't like it, they
>>> need to add in an <exclude>. That's what major release numbers are
>>> for, in my view.
>>>
>>> I don't see that as aggressive. I see it as correcting an obscure bug.
>>> I describe it as 'incompatible' because it does change behavior.
>>> However, I also claim that the behavior was a bug, not a feature. It's
>>> not documented, it's contrary to the pattern that users can control
>>> excludes and includes.
>>>
>>> No one is forced to use assembly 3.0.0. People can use 2.5.5. People
>>> who care can make a branch and make 2.5.6.
>>>
>>> In other words, I accept your logic in general, but I don't agree that
>>> it's applicable to these particular circumstances. If I felt that it
>>> was even faintly useful to retain this behavior, I'd add a new boolean
>>> to the model to retain the behavior by default. But it seems stupid to
>>> me to add the conceptual overhead for that purpose.
>>>
>>> However, if the community wants a boolean, I'll knock in a boolean,
>>> and then release. It would be called:
>>>
>>> <useDefaultFilteredFormattedExcludes>
>>>
>>> and it would be true by default.
>>>
>>> Heck, if even one member of the community really thinks that backwards
>>> preservation of this bug across a major release boundary is
>>> worthwhile, I'll do it. It will take 15 minutes.
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Jul 14, 2015 at 11:28 AM, Jason van Zyl <ja...@takari.io> wrote:
>>>> This is why I keep stuff that I want to move on a self-interested/aggressive path not at Apache. What’s here needs to consider the best interest of all users.
>>>>
>>>> If you’re basically going to make the next version incompatible for anyone who upgrades because you need something I don’t think that’s acceptable.
>>>>
>>>> I think taking some liberties is fine if you’ve contributed a ton, but if every user of the assembly plugin is going to get punched in the face when they upgrade to the only available next version I think that’s pretty crappy. You should fork it and make your client use your fork, it should be your problem not every users problem because you need an expedient fix. I hold on to spot fixes for customers for months until I can find a way to make it work generally or I just maintain the fork.
>>>>
>>>>> On Jul 14, 2015, at 11:15 AM, Benson Margulies <bi...@gmail.com> wrote:
>>>>>
>>>>> I have selfish/professional reasons to desire a release with a fix to
>>>>> MASSEMBLY-777, and the fix, involving an intentional incompatibility,
>>>>> needs to be 3.0.0, and, anyhow, the pom is all set up for 3.0.0 to be
>>>>> next. So I plan to start the process tomorrow morning EDT unless
>>>>> someone objects.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Jason
>>>>
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder, Takari and Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> http://twitter.com/takari_io
>>>> ---------------------------------------------------------
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Takari and Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> ---------------------------------------------------------
>>
>> A language that doesn’t affect the way you think about programming is not worth knowing.
>>
>> -- Alan Perlis
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------
We all have problems. How we deal with them is a measure of our worth.
-- Unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Intend to release maven-assembly-plugin 3.0.0
Posted by Dawid Weiss <da...@gmail.com>.
> I considered, even, sending email proposing to remove the
> long-deprecated goals from this plugin.
Not a Maven committer, but I'm with Benson on this one. If there is an
opportunity to clean it up, please do it. When I upgrade POMs to new
major versions I'd expect them to fail if I keep using something that
has been long deprecated (and isn't actively maintained). Otherwise
what's the point of upgrading to a new major version?
Dawid
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Intend to release maven-assembly-plugin 3.0.0
Posted by Benson Margulies <bi...@gmail.com>.
On Tue, Jul 14, 2015 at 11:48 AM, Jason van Zyl <ja...@takari.io> wrote:
> Ultimately your call. If users can upgrade and existing configuration will work there’s no issue. If it breaks the user simply upgrading for something you need need for expediency not so much. If it’s the first case there’s no issue, if it’s the second then I would take the 15 minutes to make it backward compatible and therefore a non-issue then it’s win-win. I have no issue with any committer punching in fixes, even for self-interested reasons, but personally I try my best to make it transparent over upgrades.
Jason, thank you. I completely agree about transparency in general. It
seems to me that this hinges on the definition of 'works'. Does adding
an unwanted file to the output constitute 'not working'? I could
imagine arguments in both directions. The other consideration here, in
my head, is that there's a cost to an ever-growing list of obscure
options in the assembly descriptor, and that a major version boundary,
teed up for other good reasons, is an opportunity to clean house. I
considered, even, sending email proposing to remove the
long-deprecated goals from this plugin.
For now, I've decided to hold off a day or two and see what other
people think; I have a local workaround. And for the record, this
isn't 'my client', this is me doing my day job using Maven where I ran
into this.
>
>> On Jul 14, 2015, at 11:36 AM, Benson Margulies <bi...@gmail.com> wrote:
>>
>> Jason, I don't think that this constitutes a punch in the face of
>> anyone for any purpose.
>>
>> Did you actually read the JIRA? I've removed a file exclusion from
>> file sets. So, if someone was depending on the undocumented fact that
>> the assembly plugin would refuse to copy a file named (e.g.)
>> lexicon.filtered, they will now find this file in their output, if and
>> only if they upgrade to 3.0.0; and then, if they don't like it, they
>> need to add in an <exclude>. That's what major release numbers are
>> for, in my view.
>>
>> I don't see that as aggressive. I see it as correcting an obscure bug.
>> I describe it as 'incompatible' because it does change behavior.
>> However, I also claim that the behavior was a bug, not a feature. It's
>> not documented, it's contrary to the pattern that users can control
>> excludes and includes.
>>
>> No one is forced to use assembly 3.0.0. People can use 2.5.5. People
>> who care can make a branch and make 2.5.6.
>>
>> In other words, I accept your logic in general, but I don't agree that
>> it's applicable to these particular circumstances. If I felt that it
>> was even faintly useful to retain this behavior, I'd add a new boolean
>> to the model to retain the behavior by default. But it seems stupid to
>> me to add the conceptual overhead for that purpose.
>>
>> However, if the community wants a boolean, I'll knock in a boolean,
>> and then release. It would be called:
>>
>> <useDefaultFilteredFormattedExcludes>
>>
>> and it would be true by default.
>>
>> Heck, if even one member of the community really thinks that backwards
>> preservation of this bug across a major release boundary is
>> worthwhile, I'll do it. It will take 15 minutes.
>>
>>
>>
>>
>>
>> On Tue, Jul 14, 2015 at 11:28 AM, Jason van Zyl <ja...@takari.io> wrote:
>>> This is why I keep stuff that I want to move on a self-interested/aggressive path not at Apache. What’s here needs to consider the best interest of all users.
>>>
>>> If you’re basically going to make the next version incompatible for anyone who upgrades because you need something I don’t think that’s acceptable.
>>>
>>> I think taking some liberties is fine if you’ve contributed a ton, but if every user of the assembly plugin is going to get punched in the face when they upgrade to the only available next version I think that’s pretty crappy. You should fork it and make your client use your fork, it should be your problem not every users problem because you need an expedient fix. I hold on to spot fixes for customers for months until I can find a way to make it work generally or I just maintain the fork.
>>>
>>>> On Jul 14, 2015, at 11:15 AM, Benson Margulies <bi...@gmail.com> wrote:
>>>>
>>>> I have selfish/professional reasons to desire a release with a fix to
>>>> MASSEMBLY-777, and the fix, involving an intentional incompatibility,
>>>> needs to be 3.0.0, and, anyhow, the pom is all set up for 3.0.0 to be
>>>> next. So I plan to start the process tomorrow morning EDT unless
>>>> someone objects.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Takari and Apache Maven
>>> http://twitter.com/jvanzyl
>>> http://twitter.com/takari_io
>>> ---------------------------------------------------------
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
> A language that doesn’t affect the way you think about programming is not worth knowing.
>
> -- Alan Perlis
>
>
>
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Intend to release maven-assembly-plugin 3.0.0
Posted by Jason van Zyl <ja...@takari.io>.
Ultimately your call. If users can upgrade and existing configuration will work there’s no issue. If it breaks the user simply upgrading for something you need need for expediency not so much. If it’s the first case there’s no issue, if it’s the second then I would take the 15 minutes to make it backward compatible and therefore a non-issue then it’s win-win. I have no issue with any committer punching in fixes, even for self-interested reasons, but personally I try my best to make it transparent over upgrades.
> On Jul 14, 2015, at 11:36 AM, Benson Margulies <bi...@gmail.com> wrote:
>
> Jason, I don't think that this constitutes a punch in the face of
> anyone for any purpose.
>
> Did you actually read the JIRA? I've removed a file exclusion from
> file sets. So, if someone was depending on the undocumented fact that
> the assembly plugin would refuse to copy a file named (e.g.)
> lexicon.filtered, they will now find this file in their output, if and
> only if they upgrade to 3.0.0; and then, if they don't like it, they
> need to add in an <exclude>. That's what major release numbers are
> for, in my view.
>
> I don't see that as aggressive. I see it as correcting an obscure bug.
> I describe it as 'incompatible' because it does change behavior.
> However, I also claim that the behavior was a bug, not a feature. It's
> not documented, it's contrary to the pattern that users can control
> excludes and includes.
>
> No one is forced to use assembly 3.0.0. People can use 2.5.5. People
> who care can make a branch and make 2.5.6.
>
> In other words, I accept your logic in general, but I don't agree that
> it's applicable to these particular circumstances. If I felt that it
> was even faintly useful to retain this behavior, I'd add a new boolean
> to the model to retain the behavior by default. But it seems stupid to
> me to add the conceptual overhead for that purpose.
>
> However, if the community wants a boolean, I'll knock in a boolean,
> and then release. It would be called:
>
> <useDefaultFilteredFormattedExcludes>
>
> and it would be true by default.
>
> Heck, if even one member of the community really thinks that backwards
> preservation of this bug across a major release boundary is
> worthwhile, I'll do it. It will take 15 minutes.
>
>
>
>
>
> On Tue, Jul 14, 2015 at 11:28 AM, Jason van Zyl <ja...@takari.io> wrote:
>> This is why I keep stuff that I want to move on a self-interested/aggressive path not at Apache. What’s here needs to consider the best interest of all users.
>>
>> If you’re basically going to make the next version incompatible for anyone who upgrades because you need something I don’t think that’s acceptable.
>>
>> I think taking some liberties is fine if you’ve contributed a ton, but if every user of the assembly plugin is going to get punched in the face when they upgrade to the only available next version I think that’s pretty crappy. You should fork it and make your client use your fork, it should be your problem not every users problem because you need an expedient fix. I hold on to spot fixes for customers for months until I can find a way to make it work generally or I just maintain the fork.
>>
>>> On Jul 14, 2015, at 11:15 AM, Benson Margulies <bi...@gmail.com> wrote:
>>>
>>> I have selfish/professional reasons to desire a release with a fix to
>>> MASSEMBLY-777, and the fix, involving an intentional incompatibility,
>>> needs to be 3.0.0, and, anyhow, the pom is all set up for 3.0.0 to be
>>> next. So I plan to start the process tomorrow morning EDT unless
>>> someone objects.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Takari and Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> ---------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------
A language that doesn’t affect the way you think about programming is not worth knowing.
-- Alan Perlis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Intend to release maven-assembly-plugin 3.0.0
Posted by Benson Margulies <bi...@gmail.com>.
Jason, I don't think that this constitutes a punch in the face of
anyone for any purpose.
Did you actually read the JIRA? I've removed a file exclusion from
file sets. So, if someone was depending on the undocumented fact that
the assembly plugin would refuse to copy a file named (e.g.)
lexicon.filtered, they will now find this file in their output, if and
only if they upgrade to 3.0.0; and then, if they don't like it, they
need to add in an <exclude>. That's what major release numbers are
for, in my view.
I don't see that as aggressive. I see it as correcting an obscure bug.
I describe it as 'incompatible' because it does change behavior.
However, I also claim that the behavior was a bug, not a feature. It's
not documented, it's contrary to the pattern that users can control
excludes and includes.
No one is forced to use assembly 3.0.0. People can use 2.5.5. People
who care can make a branch and make 2.5.6.
In other words, I accept your logic in general, but I don't agree that
it's applicable to these particular circumstances. If I felt that it
was even faintly useful to retain this behavior, I'd add a new boolean
to the model to retain the behavior by default. But it seems stupid to
me to add the conceptual overhead for that purpose.
However, if the community wants a boolean, I'll knock in a boolean,
and then release. It would be called:
<useDefaultFilteredFormattedExcludes>
and it would be true by default.
Heck, if even one member of the community really thinks that backwards
preservation of this bug across a major release boundary is
worthwhile, I'll do it. It will take 15 minutes.
On Tue, Jul 14, 2015 at 11:28 AM, Jason van Zyl <ja...@takari.io> wrote:
> This is why I keep stuff that I want to move on a self-interested/aggressive path not at Apache. What’s here needs to consider the best interest of all users.
>
> If you’re basically going to make the next version incompatible for anyone who upgrades because you need something I don’t think that’s acceptable.
>
> I think taking some liberties is fine if you’ve contributed a ton, but if every user of the assembly plugin is going to get punched in the face when they upgrade to the only available next version I think that’s pretty crappy. You should fork it and make your client use your fork, it should be your problem not every users problem because you need an expedient fix. I hold on to spot fixes for customers for months until I can find a way to make it work generally or I just maintain the fork.
>
>> On Jul 14, 2015, at 11:15 AM, Benson Margulies <bi...@gmail.com> wrote:
>>
>> I have selfish/professional reasons to desire a release with a fix to
>> MASSEMBLY-777, and the fix, involving an intentional incompatibility,
>> needs to be 3.0.0, and, anyhow, the pom is all set up for 3.0.0 to be
>> next. So I plan to start the process tomorrow morning EDT unless
>> someone objects.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Intend to release maven-assembly-plugin 3.0.0
Posted by Jason van Zyl <ja...@takari.io>.
This is why I keep stuff that I want to move on a self-interested/aggressive path not at Apache. What’s here needs to consider the best interest of all users.
If you’re basically going to make the next version incompatible for anyone who upgrades because you need something I don’t think that’s acceptable.
I think taking some liberties is fine if you’ve contributed a ton, but if every user of the assembly plugin is going to get punched in the face when they upgrade to the only available next version I think that’s pretty crappy. You should fork it and make your client use your fork, it should be your problem not every users problem because you need an expedient fix. I hold on to spot fixes for customers for months until I can find a way to make it work generally or I just maintain the fork.
> On Jul 14, 2015, at 11:15 AM, Benson Margulies <bi...@gmail.com> wrote:
>
> I have selfish/professional reasons to desire a release with a fix to
> MASSEMBLY-777, and the fix, involving an intentional incompatibility,
> needs to be 3.0.0, and, anyhow, the pom is all set up for 3.0.0 to be
> next. So I plan to start the process tomorrow morning EDT unless
> someone objects.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Intend to release maven-assembly-plugin 3.0.0
Posted by Benson Margulies <bi...@gmail.com>.
A little list,
1: we have an agreement, as a project, to bump major versions when
someone is willing to do the Maven 3.x/Java 1.6 transition. There does
not have to be any particularly interesting set of changes to the
plugin, just that. I didn't make the POM changes, for that, I just
found them, and thought: "Great! I can make this slightly incompatible
change." If they are not, in fact, ready, then neither I nor anyone
else should release 3.0.0 until they are. But I object to the idea
that the trunk of a plugin has to sit in Java 1.5 purgatory until
someone comes up with something wonderful to add in.
2: I consider it very ugly that someone decided to implement filtering
by littering the tree with crap files and then excluding them out. But
I agree that I can't go busting filtering. So, I see three
possibilities:
a: find a way to move the filtering intermediates to some other location
b: add the excludes only if filtering is actually happening -- but I
don't see a good way to do that.
c: add a parameter to the model to allow the exclusion to be disabled.
I confess that my energy level here is only consistent with (c), so
unless someone else steps up for (a) that's what I'll do next.
On Tue, Jul 14, 2015 at 2:56 PM, Karl Heinz Marbaise <kh...@gmx.de> wrote:
> Hi Kristian,
>
> On 7/14/15 8:51 PM, Kristian Rosenvold wrote:
>>
>> I have already updated this requirements to maven 3.x and moved the
>> version to 3.0.0.
>
>
> If this is already done which i not deeply dived/checked etc.
>
> so no problem go for it...
>
>
> If you for some reason think Benson requires to jump
>>
>> through some special hoops for legacy support on this I'd find that
>> largely amusing, given the versioning strategy we have been discussing
>> wrt 3.x move.
>>
>> Kristian
>>
>>
>> 2015-07-14 19:13 GMT+02:00 Karl Heinz Marbaise <khmarbaise@gmx.de
>> <ma...@gmx.de>>:
>>
>> Hi Benson,
>>
>> I have taken a look and i see only a small change which is very good
>> idea to do so, but which means the upgrade to 3.0.0 does not make
>> sense.
>>
>> An update to 3.0.0 indicates very important things to the user which
>> is not the case and that means 3.0.0 is more compatible to 2.5.X
>> which shouldn't be done, cause that would close the door for making
>> real incompatible changes to maven-assembly-plugin in release 3.0.0...
>>
>> So my suggestions is to create a branch from the last release 2.5.5
>> and make a 2.5.6 release instead which contains your fix and
>> furthermore you can add the fluido skin change as well with an
>> appropriate JIRA reference...
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>>
>> O7/14/15 5:15 PM, Benson Margulies wrote:
>>
>> I have selfish/professional reasons to desire a release with a
>> fix to
>> MASSEMBLY-777, and the fix, involving an intentional
>> incompatibility,
>> needs to be 3.0.0, and, anyhow, the pom is all set up for 3.0.0
>> to be
>> next. So I plan to start the process tomorrow morning EDT unless
>> someone objects.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> <ma...@maven.apache.org>
>> For additional commands, e-mail: dev-help@maven.apache.org
>> <ma...@maven.apache.org>
>>
>>
>>
>>
>> Mit freundlichem Gruß
>> Karl-Heinz Marbaise
>> --
>> SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415
>> 893 <tel:%2B49%20%280%29%202405%20%2F%20415%20893>
>> Dipl.Ing.(FH) Karl-Heinz Marbaise USt.IdNr: DE191347579
>> Hauptstrasse 177
>> 52146 Würselen http://www.soebes.de
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> <ma...@maven.apache.org>
>> For additional commands, e-mail: dev-help@maven.apache.org
>> <ma...@maven.apache.org>
>>
>>
>
>
> Mit freundlichem Gruß
> Karl-Heinz Marbaise
> --
> SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893
> Dipl.Ing.(FH) Karl-Heinz Marbaise USt.IdNr: DE191347579
> Hauptstrasse 177
> 52146 Würselen http://www.soebes.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Intend to release maven-assembly-plugin 3.0.0
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi Kristian,
On 7/14/15 8:51 PM, Kristian Rosenvold wrote:
> I have already updated this requirements to maven 3.x and moved the
> version to 3.0.0.
If this is already done which i not deeply dived/checked etc.
so no problem go for it...
If you for some reason think Benson requires to jump
> through some special hoops for legacy support on this I'd find that
> largely amusing, given the versioning strategy we have been discussing
> wrt 3.x move.
>
> Kristian
>
>
> 2015-07-14 19:13 GMT+02:00 Karl Heinz Marbaise <khmarbaise@gmx.de
> <ma...@gmx.de>>:
>
> Hi Benson,
>
> I have taken a look and i see only a small change which is very good
> idea to do so, but which means the upgrade to 3.0.0 does not make sense.
>
> An update to 3.0.0 indicates very important things to the user which
> is not the case and that means 3.0.0 is more compatible to 2.5.X
> which shouldn't be done, cause that would close the door for making
> real incompatible changes to maven-assembly-plugin in release 3.0.0...
>
> So my suggestions is to create a branch from the last release 2.5.5
> and make a 2.5.6 release instead which contains your fix and
> furthermore you can add the fluido skin change as well with an
> appropriate JIRA reference...
>
> Kind regards
> Karl Heinz Marbaise
>
>
> O7/14/15 5:15 PM, Benson Margulies wrote:
>
> I have selfish/professional reasons to desire a release with a
> fix to
> MASSEMBLY-777, and the fix, involving an intentional
> incompatibility,
> needs to be 3.0.0, and, anyhow, the pom is all set up for 3.0.0
> to be
> next. So I plan to start the process tomorrow morning EDT unless
> someone objects.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> <ma...@maven.apache.org>
> For additional commands, e-mail: dev-help@maven.apache.org
> <ma...@maven.apache.org>
>
>
>
>
> Mit freundlichem Gruß
> Karl-Heinz Marbaise
> --
> SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415
> 893 <tel:%2B49%20%280%29%202405%20%2F%20415%20893>
> Dipl.Ing.(FH) Karl-Heinz Marbaise USt.IdNr: DE191347579
> Hauptstrasse 177
> 52146 Würselen http://www.soebes.de
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> <ma...@maven.apache.org>
> For additional commands, e-mail: dev-help@maven.apache.org
> <ma...@maven.apache.org>
>
>
Mit freundlichem Gruß
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz Marbaise USt.IdNr: DE191347579
Hauptstrasse 177
52146 Würselen http://www.soebes.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Intend to release maven-assembly-plugin 3.0.0
Posted by Kristian Rosenvold <kr...@gmail.com>.
I have already updated this requirements to maven 3.x and moved the version
to 3.0.0. If you for some reason think Benson requires to jump through some
special hoops for legacy support on this I'd find that largely amusing,
given the versioning strategy we have been discussing wrt 3.x move.
Kristian
2015-07-14 19:13 GMT+02:00 Karl Heinz Marbaise <kh...@gmx.de>:
> Hi Benson,
>
> I have taken a look and i see only a small change which is very good idea
> to do so, but which means the upgrade to 3.0.0 does not make sense.
>
> An update to 3.0.0 indicates very important things to the user which is
> not the case and that means 3.0.0 is more compatible to 2.5.X which
> shouldn't be done, cause that would close the door for making real
> incompatible changes to maven-assembly-plugin in release 3.0.0...
>
> So my suggestions is to create a branch from the last release 2.5.5 and
> make a 2.5.6 release instead which contains your fix and furthermore you
> can add the fluido skin change as well with an appropriate JIRA reference...
>
> Kind regards
> Karl Heinz Marbaise
>
>
> O7/14/15 5:15 PM, Benson Margulies wrote:
>
>> I have selfish/professional reasons to desire a release with a fix to
>> MASSEMBLY-777, and the fix, involving an intentional incompatibility,
>> needs to be 3.0.0, and, anyhow, the pom is all set up for 3.0.0 to be
>> next. So I plan to start the process tomorrow morning EDT unless
>> someone objects.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>>
>
> Mit freundlichem Gruß
> Karl-Heinz Marbaise
> --
> SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893
> Dipl.Ing.(FH) Karl-Heinz Marbaise USt.IdNr: DE191347579
> Hauptstrasse 177
> 52146 Würselen http://www.soebes.de
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Intend to release maven-assembly-plugin 3.0.0
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi Benson,
I have taken a look and i see only a small change which is very good
idea to do so, but which means the upgrade to 3.0.0 does not make sense.
An update to 3.0.0 indicates very important things to the user which is
not the case and that means 3.0.0 is more compatible to 2.5.X which
shouldn't be done, cause that would close the door for making real
incompatible changes to maven-assembly-plugin in release 3.0.0...
So my suggestions is to create a branch from the last release 2.5.5 and
make a 2.5.6 release instead which contains your fix and furthermore
you can add the fluido skin change as well with an appropriate JIRA
reference...
Kind regards
Karl Heinz Marbaise
O7/14/15 5:15 PM, Benson Margulies wrote:
> I have selfish/professional reasons to desire a release with a fix to
> MASSEMBLY-777, and the fix, involving an intentional incompatibility,
> needs to be 3.0.0, and, anyhow, the pom is all set up for 3.0.0 to be
> next. So I plan to start the process tomorrow morning EDT unless
> someone objects.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Mit freundlichem Gruß
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz Marbaise USt.IdNr: DE191347579
Hauptstrasse 177
52146 Würselen http://www.soebes.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org