You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by John Casey <ca...@gmail.com> on 2007/04/06 16:55:04 UTC
[vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1
Hi everyone,
This is the third attempt, after fixing:
* http://jira.codehaus.org/browse/MASSEMBLY-194<http://jira.codehaus.org/browse/MASSEMBLY-155>
This bugfix actualy adds a new flag to the dependencySet, called
useTransitiveFiltering, which allows you to enable filtering by matching a
given pattern against the transitive dependency path of the given artifact
(in addition to all the other ways). By default, this is disabled
(useTransitiveFiltering == false), in order to preserve backward compat with
version 2.1.
So, let's try this one more time:
I wanted to call a vote to release a beta version of the new assembly
plugin. There are still some outstanding issues (though not as many as jira
would have you believe; they just need tests), but I think we're at around
95-99% backward compatibility and the new features seem to be working well.
It's been just sitting in SVN for quite awhile now, and many people are
using it directly from there. I'd like to provide better support for those
people, and start getting more feedback on exactly what's still broken.
The change list is pretty large, but is mainly concerned with refactoring
the plugin away from the old monolithic approach to one that uses phases to
handle the different descriptor sections, along with common task classes to
handle behavior shared between phases.
Road Map:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126&styleName=Html&version=12617
Tag:
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plugin-2.2-beta-1
Staging repository:
http://people.apache.org/~jdcasey/stage/repo<http://people.apache.org/%7Ejdcasey/stage/repo>
So, let's try 72h +1/+0/-1. Please cast your votes!
Here's my +1.
-john
Re: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1
Posted by Patrick Schneider <ps...@gmail.com>.
+1
I've been using 2.2-SNAP for some time now as well, but mainly only with
small test projects.
On 4/10/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
>
> +1
>
> Thought I voted but I guess not. I've been running a snapshot for a long
> time now anyway. A release can only help to get feedback about what to
> fix.
>
> -----Original Message-----
> From: John Casey [mailto:casey.john.d@gmail.com]
> Sent: Friday, April 06, 2007 10:55 AM
> To: Maven Developers List
> Subject: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1
>
> Hi everyone,
>
> This is the third attempt, after fixing:
>
> *
> http://jira.codehaus.org/browse/MASSEMBLY-194<http://jira.codehaus.org/b
> rowse/MASSEMBLY-155>
>
> This bugfix actualy adds a new flag to the dependencySet, called
> useTransitiveFiltering, which allows you to enable filtering by matching
> a
> given pattern against the transitive dependency path of the given
> artifact
> (in addition to all the other ways). By default, this is disabled
> (useTransitiveFiltering == false), in order to preserve backward compat
> with
> version 2.1.
>
> So, let's try this one more time:
>
> I wanted to call a vote to release a beta version of the new assembly
> plugin. There are still some outstanding issues (though not as many as
> jira
> would have you believe; they just need tests), but I think we're at
> around
> 95-99% backward compatibility and the new features seem to be working
> well.
> It's been just sitting in SVN for quite awhile now, and many people are
> using it directly from there. I'd like to provide better support for
> those
> people, and start getting more feedback on exactly what's still broken.
>
> The change list is pretty large, but is mainly concerned with
> refactoring
> the plugin away from the old monolithic approach to one that uses phases
> to
> handle the different descriptor sections, along with common task classes
> to
> handle behavior shared between phases.
>
> Road Map:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126&styleNa
> me=Html&version=12617
>
>
> Tag:
>
> http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plugin
> -2.2-beta-1
>
>
> Staging repository:
>
> http://people.apache.org/~jdcasey/stage/repo<http://people.apache.org/%7
> Ejdcasey/stage/repo>
>
> So, let's try 72h +1/+0/-1. Please cast your votes!
>
> Here's my +1.
>
> -john
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
RE: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
+1
Thought I voted but I guess not. I've been running a snapshot for a long
time now anyway. A release can only help to get feedback about what to
fix.
-----Original Message-----
From: John Casey [mailto:casey.john.d@gmail.com]
Sent: Friday, April 06, 2007 10:55 AM
To: Maven Developers List
Subject: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1
Hi everyone,
This is the third attempt, after fixing:
*
http://jira.codehaus.org/browse/MASSEMBLY-194<http://jira.codehaus.org/b
rowse/MASSEMBLY-155>
This bugfix actualy adds a new flag to the dependencySet, called
useTransitiveFiltering, which allows you to enable filtering by matching
a
given pattern against the transitive dependency path of the given
artifact
(in addition to all the other ways). By default, this is disabled
(useTransitiveFiltering == false), in order to preserve backward compat
with
version 2.1.
So, let's try this one more time:
I wanted to call a vote to release a beta version of the new assembly
plugin. There are still some outstanding issues (though not as many as
jira
would have you believe; they just need tests), but I think we're at
around
95-99% backward compatibility and the new features seem to be working
well.
It's been just sitting in SVN for quite awhile now, and many people are
using it directly from there. I'd like to provide better support for
those
people, and start getting more feedback on exactly what's still broken.
The change list is pretty large, but is mainly concerned with
refactoring
the plugin away from the old monolithic approach to one that uses phases
to
handle the different descriptor sections, along with common task classes
to
handle behavior shared between phases.
Road Map:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126&styleNa
me=Html&version=12617
Tag:
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plugin
-2.2-beta-1
Staging repository:
http://people.apache.org/~jdcasey/stage/repo<http://people.apache.org/%7
Ejdcasey/stage/repo>
So, let's try 72h +1/+0/-1. Please cast your votes!
Here's my +1.
-john
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1
Posted by John Casey <ca...@gmail.com>.
+1 binding: John C, Stephane, Brian, Jason
+1 non-binding: Dan K, Patrick
-1 (non-veto): Brett
I'll proceed with the release.
Thanks,
John
On 4/6/07, John Casey <ca...@gmail.com> wrote:
>
> Hi everyone,
>
> This is the third attempt, after fixing:
>
> * http://jira.codehaus.org/browse/MASSEMBLY-194
> <http://jira.codehaus.org/browse/MASSEMBLY-155>
>
> This bugfix actualy adds a new flag to the dependencySet, called
> useTransitiveFiltering, which allows you to enable filtering by matching a
> given pattern against the transitive dependency path of the given artifact
> (in addition to all the other ways). By default, this is disabled
> (useTransitiveFiltering == false), in order to preserve backward compat with
> version 2.1.
>
> So, let's try this one more time:
>
> I wanted to call a vote to release a beta version of the new assembly
> plugin. There are still some outstanding issues (though not as many as jira
> would have you believe; they just need tests), but I think we're at around
> 95-99% backward compatibility and the new features seem to be working well.
> It's been just sitting in SVN for quite awhile now, and many people are
> using it directly from there. I'd like to provide better support for those
> people, and start getting more feedback on exactly what's still broken.
>
> The change list is pretty large, but is mainly concerned with refactoring
> the plugin away from the old monolithic approach to one that uses phases to
> handle the different descriptor sections, along with common task classes to
> handle behavior shared between phases.
>
> Road Map:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126&styleName=Html&version=12617
>
>
> Tag:
>
> http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plugin-2.2-beta-1
>
>
> Staging repository:
>
> http://people.apache.org/~jdcasey/stage/repo<http://people.apache.org/%7Ejdcasey/stage/repo>
>
> So, let's try 72h +1/+0/-1. Please cast your votes!
>
> Here's my +1.
>
> -john
>
RE: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
"So maybe we should publish far and wide the best practice of pegging
the plugin version, and require it in 2.1...then write a plugin to list
the available versions for a plugin, so users can check periodically.
That would make life a little easier for users."
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1
Posted by jallen <jo...@hotmail.com>.
+1
John Casey wrote:
>
> So maybe we should publish far and wide the best practice of pegging the
> plugin version, and require it in 2.1...then write a plugin to list the
> available versions for a plugin, so users can check periodically. That
> would
> make life a little easier for users.
>
> -j
>
> On 4/10/07, Jason van Zyl <ja...@maven.org> wrote:
>>
>>
>> On 10 Apr 07, at 12:42 PM 10 Apr 07, Brian E. Fox wrote:
>>
>> > "This is a MUCH bigger problem than we seem to recognize. Who
>> > wants to
>> > send the email to the users@ list to tell them that, oh, yeah, they
>> > need
>> > to specify versions for all of their plugins in the POM? I'm not wild
>> > about it, but I think that's the only way out...and I'm willing to
>> > send
>> > that email."
>> >
>>
>> We can't do this in 2.0.x but it needs to be mandatory in 2.1.
>>
>> > We recently discussed this on this list (maybe even related to
>> > Assembly...no it was Brett's proposal for a separate Alpha repo).
>> > If we
>> > are to encourage best practices, then we really should encourage the
>> > plugin versions to be set in the poms or pluginManagement. I would
>> > even
>> > assert that it should be required in 2.1 as it is for dependenceis
>> > now.
>>
>> Yes, otherwise there is no deterministic way to know what version of
>> a plugin was used. You can look in the local repo and look for the
>> latest version but that's no guarantee either. It needs to be as
>> structured as versions for any dependency. As I noted before the onus
>> is on us to make it easy to select the latest version but everything
>> needs to be versioned. The magic latest release lookup has not been a
>> boon IMO.
>>
>> Jason.
>>
>> > No build team who is concerned about reproducibility would really
>> > allow
>> > the versions to be uncontrolled and entirely up to the developers
>> > environment. (If they are, maybe they don't realize this is occuring).
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>>
>
>
--
View this message in context: http://www.nabble.com/-vote--Attempt-3%3A-Release-maven-assembly-plugin-2.2-beta-1-tf3537158s177.html#a9969910
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1
Posted by John Casey <ca...@gmail.com>.
So maybe we should publish far and wide the best practice of pegging the
plugin version, and require it in 2.1...then write a plugin to list the
available versions for a plugin, so users can check periodically. That would
make life a little easier for users.
-j
On 4/10/07, Jason van Zyl <ja...@maven.org> wrote:
>
>
> On 10 Apr 07, at 12:42 PM 10 Apr 07, Brian E. Fox wrote:
>
> > "This is a MUCH bigger problem than we seem to recognize. Who
> > wants to
> > send the email to the users@ list to tell them that, oh, yeah, they
> > need
> > to specify versions for all of their plugins in the POM? I'm not wild
> > about it, but I think that's the only way out...and I'm willing to
> > send
> > that email."
> >
>
> We can't do this in 2.0.x but it needs to be mandatory in 2.1.
>
> > We recently discussed this on this list (maybe even related to
> > Assembly...no it was Brett's proposal for a separate Alpha repo).
> > If we
> > are to encourage best practices, then we really should encourage the
> > plugin versions to be set in the poms or pluginManagement. I would
> > even
> > assert that it should be required in 2.1 as it is for dependenceis
> > now.
>
> Yes, otherwise there is no deterministic way to know what version of
> a plugin was used. You can look in the local repo and look for the
> latest version but that's no guarantee either. It needs to be as
> structured as versions for any dependency. As I noted before the onus
> is on us to make it easy to select the latest version but everything
> needs to be versioned. The magic latest release lookup has not been a
> boon IMO.
>
> Jason.
>
> > No build team who is concerned about reproducibility would really
> > allow
> > the versions to be uncontrolled and entirely up to the developers
> > environment. (If they are, maybe they don't realize this is occuring).
> >
> > ---------------------------------------------------------------------
> > 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: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1 -> lock down of plugin versions
Posted by John Casey <ca...@gmail.com>.
The idea originally was that LATEST might refer to a snapshot release, but
that RELEASE was the latest plugin release. Of course, all of this
completely ignores any notion of versions that have implications for
backward compatibility. In the Maven 2.0.x, all plugin releases are assumed
to be minor/point releases of the same major version.
-john
On 4/11/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
>
> I never use either to be honest so I'm not actually sure what the
> difference is.
>
> -----Original Message-----
> From: Barrie Treloar [mailto:baerrach@gmail.com]
> Sent: Wednesday, April 11, 2007 6:44 PM
> To: Maven Developers List
> Subject: Re: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1
> -> lock down of plugin versions
>
> On 4/12/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
> > I think if we just change the plugin resolution so that it doesn't
> > assume "RELEASE" if no version is set, it should be pretty easy right?
> > IE someone can still put RELEASE as a version if they want to, but we
> > would require something to be set and not just assume it. Or should we
> > abandon RELEASE all together?
>
> Is this because LATEST and RELEASE might not be the same thing?
>
> ---------------------------------------------------------------------
> 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: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1 -> lock down of plugin versions
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
I never use either to be honest so I'm not actually sure what the
difference is.
-----Original Message-----
From: Barrie Treloar [mailto:baerrach@gmail.com]
Sent: Wednesday, April 11, 2007 6:44 PM
To: Maven Developers List
Subject: Re: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1
-> lock down of plugin versions
On 4/12/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
> I think if we just change the plugin resolution so that it doesn't
> assume "RELEASE" if no version is set, it should be pretty easy right?
> IE someone can still put RELEASE as a version if they want to, but we
> would require something to be set and not just assume it. Or should we
> abandon RELEASE all together?
Is this because LATEST and RELEASE might not be the same thing?
---------------------------------------------------------------------
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: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1 -> lock down of plugin versions
Posted by Barrie Treloar <ba...@gmail.com>.
On 4/12/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
> I think if we just change the plugin resolution so that it doesn't
> assume "RELEASE" if no version is set, it should be pretty easy right?
> IE someone can still put RELEASE as a version if they want to, but we
> would require something to be set and not just assume it. Or should we
> abandon RELEASE all together?
Is this because LATEST and RELEASE might not be the same thing?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1 -> lock down of plugin versions
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
I think if we just change the plugin resolution so that it doesn't
assume "RELEASE" if no version is set, it should be pretty easy right?
IE someone can still put RELEASE as a version if they want to, but we
would require something to be set and not just assume it. Or should we
abandon RELEASE all together?
-----Original Message-----
From: Arik Kfir [mailto:arikkfir@gmail.com]
Sent: Wednesday, April 11, 2007 12:39 PM
To: Maven Developers List
Subject: Re: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1
-> lock down of plugin versions
+1 for that!
On 4/11/07, Geoffrey De Smet <ge...@gmail.com> wrote:
>
>
>
>
> >> "they need to specify versions for all of their plugins in the
POM"
> >
> > We can't do this in 2.0.x but it needs to be mandatory in 2.1.
> >
>
> Good! :)
>
> In my experience with spring-richclient most of the problems of an
> instable build went away the day I locked down all versions.
>
> However you could do 2 things to make our lives easier:
>
> 1) Bundle a bunch of plugins together in a version so we can just
> specify that bundle.
> Say for example "we use plugin-bundle 2.0.6" (which means we use
> assembly 2.0, site 2.0-beta5, ...).
> Of course it should be possible to make an exception on a single
> plugin in that bundle to give it another version anyway.
>
> Plugin-bundles would allow you to test more thoroughly if all plugins
> work together nicely.
>
> 2) A site report (and maybe also a mvn cmd) to receive a list of all
> plugins which can be updated. (This would be very welcome for
> dependencies too btw.)
>
> With kind regards,
> Geoffrey De Smet
>
>
> ---------------------------------------------------------------------
> 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: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1 -> lock down of plugin versions
Posted by Arik Kfir <ar...@gmail.com>.
+1 for that!
On 4/11/07, Geoffrey De Smet <ge...@gmail.com> wrote:
>
>
>
>
> >> "they need to specify versions for all of their plugins in the POM"
> >
> > We can't do this in 2.0.x but it needs to be mandatory in 2.1.
> >
>
> Good! :)
>
> In my experience with spring-richclient most of the problems of an
> instable build went away the day I locked down all versions.
>
> However you could do 2 things to make our lives easier:
>
> 1) Bundle a bunch of plugins together in a version so we can just
> specify that bundle.
> Say for example "we use plugin-bundle 2.0.6" (which means we use
> assembly 2.0, site 2.0-beta5, ...).
> Of course it should be possible to make an exception on a single plugin
> in that bundle to give it another version anyway.
>
> Plugin-bundles would allow you to test more thoroughly if all plugins
> work together nicely.
>
> 2) A site report (and maybe also a mvn cmd) to receive a list of all
> plugins which can be updated. (This would be very welcome for
> dependencies too btw.)
>
> With kind regards,
> Geoffrey De Smet
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1 ->
lock down of plugin versions
Posted by Geoffrey De Smet <ge...@gmail.com>.
>> "they need to specify versions for all of their plugins in the POM"
>
> We can't do this in 2.0.x but it needs to be mandatory in 2.1.
>
Good! :)
In my experience with spring-richclient most of the problems of an
instable build went away the day I locked down all versions.
However you could do 2 things to make our lives easier:
1) Bundle a bunch of plugins together in a version so we can just
specify that bundle.
Say for example "we use plugin-bundle 2.0.6" (which means we use
assembly 2.0, site 2.0-beta5, ...).
Of course it should be possible to make an exception on a single plugin
in that bundle to give it another version anyway.
Plugin-bundles would allow you to test more thoroughly if all plugins
work together nicely.
2) A site report (and maybe also a mvn cmd) to receive a list of all
plugins which can be updated. (This would be very welcome for
dependencies too btw.)
With kind regards,
Geoffrey De Smet
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1
Posted by Jason van Zyl <ja...@maven.org>.
On 10 Apr 07, at 12:42 PM 10 Apr 07, Brian E. Fox wrote:
> "This is a MUCH bigger problem than we seem to recognize. Who
> wants to
> send the email to the users@ list to tell them that, oh, yeah, they
> need
> to specify versions for all of their plugins in the POM? I'm not wild
> about it, but I think that's the only way out...and I'm willing to
> send
> that email."
>
We can't do this in 2.0.x but it needs to be mandatory in 2.1.
> We recently discussed this on this list (maybe even related to
> Assembly...no it was Brett's proposal for a separate Alpha repo).
> If we
> are to encourage best practices, then we really should encourage the
> plugin versions to be set in the poms or pluginManagement. I would
> even
> assert that it should be required in 2.1 as it is for dependenceis
> now.
Yes, otherwise there is no deterministic way to know what version of
a plugin was used. You can look in the local repo and look for the
latest version but that's no guarantee either. It needs to be as
structured as versions for any dependency. As I noted before the onus
is on us to make it easy to select the latest version but everything
needs to be versioned. The magic latest release lookup has not been a
boon IMO.
Jason.
> No build team who is concerned about reproducibility would really
> allow
> the versions to be uncontrolled and entirely up to the developers
> environment. (If they are, maybe they don't realize this is occuring).
>
> ---------------------------------------------------------------------
> 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: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1
Posted by John Casey <ca...@gmail.com>.
I'll go ahead and roll the beta-1 release, and we can fix the repository
problem along with the other 17 issues that are still slated for 2.2-final.
Thanks,
John
On 4/11/07, berndq <be...@gmx.net> wrote:
>
> Brian E. Fox schrieb:
> > "This is a MUCH bigger problem than we seem to recognize. Who wants to
> > send the email to the users@ list to tell them that, oh, yeah, they need
> > to specify versions for all of their plugins in the POM? I'm not wild
> > about it, but I think that's the only way out...and I'm willing to send
> > that email."
> >
> ...
> > plugin versions to be set in the poms or pluginManagement. I would even
> > assert that it should be required in 2.1 as it is for dependenceis now.
> > No build team who is concerned about reproducibility would really allow
> > the versions to be uncontrolled and entirely up to the developers
> > environment. (If they are, maybe they don't realize this is occuring).
>
> From my users point of view I totally agree and encourage you to
> enforce plugin versions in the pom, the sooner the better.
>
> thanks for your efforts.
>
> best regards
> Bernd
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1
Posted by berndq <be...@gmx.net>.
Brian E. Fox schrieb:
> "This is a MUCH bigger problem than we seem to recognize. Who wants to
> send the email to the users@ list to tell them that, oh, yeah, they need
> to specify versions for all of their plugins in the POM? I'm not wild
> about it, but I think that's the only way out...and I'm willing to send
> that email."
>
...
> plugin versions to be set in the poms or pluginManagement. I would even
> assert that it should be required in 2.1 as it is for dependenceis now.
> No build team who is concerned about reproducibility would really allow
> the versions to be uncontrolled and entirely up to the developers
> environment. (If they are, maybe they don't realize this is occuring).
From my users point of view I totally agree and encourage you to
enforce plugin versions in the pom, the sooner the better.
thanks for your efforts.
best regards
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
"This is a MUCH bigger problem than we seem to recognize. Who wants to
send the email to the users@ list to tell them that, oh, yeah, they need
to specify versions for all of their plugins in the POM? I'm not wild
about it, but I think that's the only way out...and I'm willing to send
that email."
We recently discussed this on this list (maybe even related to
Assembly...no it was Brett's proposal for a separate Alpha repo). If we
are to encourage best practices, then we really should encourage the
plugin versions to be set in the poms or pluginManagement. I would even
assert that it should be required in 2.1 as it is for dependenceis now.
No build team who is concerned about reproducibility would really allow
the versions to be uncontrolled and entirely up to the developers
environment. (If they are, maybe they don't realize this is occuring).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1
Posted by Jason van Zyl <ja...@maven.org>.
+1
On 10 Apr 07, at 12:19 PM 10 Apr 07, John Casey wrote:
> #1 gets us back into the realm of trying to decipher whether the
> behavior of
> version 2.1 has this as a *feature* or a *bug*. It's along the same
> lines as
> MASSEMBLY-194, IMO.
>
> I understand the ramifications here: Maven (at times) will
> automatically
> select the version of a plugin to use by resolving the RELEASE
> meta-version...if this (new?) version is incompatible with the bug
> workarounds in your existing assembly descriptor, all hell breaks
> loose.
> Since we cannot fix the *real* problem here - which is that Maven
> blindly
> selects whatever RELEASE resolves to, which was a *design decision*
> that we
> made at one point - we're stuck with providing endless backward
> compatibility, regardless of whether we jump the assembly plugin up to
> version 3.0 or just 2.2. Even deprecation is a problem here, since
> (depending on when you use -U) you may completely skip the versions
> that
> mark a particular "feature" as deprecated.
>
> This is a MUCH bigger problem than we seem to recognize. Who wants
> to send
> the email to the users@ list to tell them that, oh, yeah, they need to
> specify versions for all of their plugins in the POM? I'm not wild
> about it,
> but I think that's the only way out...and I'm willing to send that
> email.
>
> -john
>
> On 4/10/07, Stephane Nicoll <st...@gmail.com> wrote:
>>
>> +1
>>
>> Brett, I think (1) is a feature. If (2) does not work, let's address
>> it to a beta-2 please. We really need to release this, get feedback
>> and prepare beta-2.
>>
>> Thanks,
>> Stéphane
>>
>> On 4/8/07, Daniel Kulp <dk...@apache.org> wrote:
>> >
>> > +1
>> >
>> > Dan
>> >
>> > On Friday 06 April 2007 10:55, John Casey wrote:
>> > > Hi everyone,
>> > >
>> > > This is the third attempt, after fixing:
>> > >
>> > > *
>> > > http://jira.codehaus.org/browse/MASSEMBLY-194<http://
>> jira.codehaus.org
>> > >/browse/MASSEMBLY-155>
>> > >
>> > > This bugfix actualy adds a new flag to the dependencySet, called
>> > > useTransitiveFiltering, which allows you to enable filtering by
>> > > matching a given pattern against the transitive dependency
>> path of
>> > > the given artifact (in addition to all the other ways). By
>> default,
>> > > this is disabled (useTransitiveFiltering == false), in order to
>> > > preserve backward compat with version 2.1.
>> > >
>> > > So, let's try this one more time:
>> > >
>> > > I wanted to call a vote to release a beta version of the new
>> assembly
>> > > plugin. There are still some outstanding issues (though not as
>> many as
>> > > jira would have you believe; they just need tests), but I
>> think we're
>> > > at around 95-99% backward compatibility and the new features
>> seem to
>> > > be working well. It's been just sitting in SVN for quite
>> awhile now,
>> > > and many people are using it directly from there. I'd like to
>> provide
>> > > better support for those people, and start getting more
>> feedback on
>> > > exactly what's still broken.
>> > >
>> > > The change list is pretty large, but is mainly concerned with
>> > > refactoring the plugin away from the old monolithic approach
>> to one
>> > > that uses phases to handle the different descriptor sections,
>> along
>> > > with common task classes to handle behavior shared between
>> phases.
>> > >
>> > > Road Map:
>> > >
>> > > http://jira.codehaus.org/secure/ReleaseNote.jspa?
>> projectId=11126&style
>> > >Name=Html&version=12617
>> > >
>> > >
>> > > Tag:
>> > >
>> > > http://svn.apache.org/repos/asf/maven/plugins/tags/maven-
>> assembly-plug
>> > >in-2.2-beta-1
>> > >
>> > >
>> > > Staging repository:
>> > >
>> > > http://people.apache.org/~jdcasey/stage/repo<http://
>> people.apache.org/
>> > >%7Ejdcasey/stage/repo>
>> > >
>> > > So, let's try 72h +1/+0/-1. Please cast your votes!
>> > >
>> > > Here's my +1.
>> > >
>> > > -john
>> >
>> > --
>> > J. Daniel Kulp
>> > Principal Engineer
>> > IONA
>> > P: 781-902-8727 C: 508-380-7194
>> > daniel.kulp@iona.com
>> > http://www.dankulp.com/blog
>> >
>> >
>> ---------------------------------------------------------------------
>> > 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: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1
Posted by John Casey <ca...@gmail.com>.
#1 gets us back into the realm of trying to decipher whether the behavior of
version 2.1 has this as a *feature* or a *bug*. It's along the same lines as
MASSEMBLY-194, IMO.
I understand the ramifications here: Maven (at times) will automatically
select the version of a plugin to use by resolving the RELEASE
meta-version...if this (new?) version is incompatible with the bug
workarounds in your existing assembly descriptor, all hell breaks loose.
Since we cannot fix the *real* problem here - which is that Maven blindly
selects whatever RELEASE resolves to, which was a *design decision* that we
made at one point - we're stuck with providing endless backward
compatibility, regardless of whether we jump the assembly plugin up to
version 3.0 or just 2.2. Even deprecation is a problem here, since
(depending on when you use -U) you may completely skip the versions that
mark a particular "feature" as deprecated.
This is a MUCH bigger problem than we seem to recognize. Who wants to send
the email to the users@ list to tell them that, oh, yeah, they need to
specify versions for all of their plugins in the POM? I'm not wild about it,
but I think that's the only way out...and I'm willing to send that email.
-john
On 4/10/07, Stephane Nicoll <st...@gmail.com> wrote:
>
> +1
>
> Brett, I think (1) is a feature. If (2) does not work, let's address
> it to a beta-2 please. We really need to release this, get feedback
> and prepare beta-2.
>
> Thanks,
> Stéphane
>
> On 4/8/07, Daniel Kulp <dk...@apache.org> wrote:
> >
> > +1
> >
> > Dan
> >
> > On Friday 06 April 2007 10:55, John Casey wrote:
> > > Hi everyone,
> > >
> > > This is the third attempt, after fixing:
> > >
> > > *
> > > http://jira.codehaus.org/browse/MASSEMBLY-194<http://jira.codehaus.org
> > >/browse/MASSEMBLY-155>
> > >
> > > This bugfix actualy adds a new flag to the dependencySet, called
> > > useTransitiveFiltering, which allows you to enable filtering by
> > > matching a given pattern against the transitive dependency path of
> > > the given artifact (in addition to all the other ways). By default,
> > > this is disabled (useTransitiveFiltering == false), in order to
> > > preserve backward compat with version 2.1.
> > >
> > > So, let's try this one more time:
> > >
> > > I wanted to call a vote to release a beta version of the new assembly
> > > plugin. There are still some outstanding issues (though not as many as
> > > jira would have you believe; they just need tests), but I think we're
> > > at around 95-99% backward compatibility and the new features seem to
> > > be working well. It's been just sitting in SVN for quite awhile now,
> > > and many people are using it directly from there. I'd like to provide
> > > better support for those people, and start getting more feedback on
> > > exactly what's still broken.
> > >
> > > The change list is pretty large, but is mainly concerned with
> > > refactoring the plugin away from the old monolithic approach to one
> > > that uses phases to handle the different descriptor sections, along
> > > with common task classes to handle behavior shared between phases.
> > >
> > > Road Map:
> > >
> > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126&style
> > >Name=Html&version=12617
> > >
> > >
> > > Tag:
> > >
> > > http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plug
> > >in-2.2-beta-1
> > >
> > >
> > > Staging repository:
> > >
> > > http://people.apache.org/~jdcasey/stage/repo<http://people.apache.org/
> > >%7Ejdcasey/stage/repo>
> > >
> > > So, let's try 72h +1/+0/-1. Please cast your votes!
> > >
> > > Here's my +1.
> > >
> > > -john
> >
> > --
> > J. Daniel Kulp
> > Principal Engineer
> > IONA
> > P: 781-902-8727 C: 508-380-7194
> > daniel.kulp@iona.com
> > http://www.dankulp.com/blog
> >
> > ---------------------------------------------------------------------
> > 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: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1
Posted by Stephane Nicoll <st...@gmail.com>.
+1
Brett, I think (1) is a feature. If (2) does not work, let's address
it to a beta-2 please. We really need to release this, get feedback
and prepare beta-2.
Thanks,
Stéphane
On 4/8/07, Daniel Kulp <dk...@apache.org> wrote:
>
> +1
>
> Dan
>
> On Friday 06 April 2007 10:55, John Casey wrote:
> > Hi everyone,
> >
> > This is the third attempt, after fixing:
> >
> > *
> > http://jira.codehaus.org/browse/MASSEMBLY-194<http://jira.codehaus.org
> >/browse/MASSEMBLY-155>
> >
> > This bugfix actualy adds a new flag to the dependencySet, called
> > useTransitiveFiltering, which allows you to enable filtering by
> > matching a given pattern against the transitive dependency path of
> > the given artifact (in addition to all the other ways). By default,
> > this is disabled (useTransitiveFiltering == false), in order to
> > preserve backward compat with version 2.1.
> >
> > So, let's try this one more time:
> >
> > I wanted to call a vote to release a beta version of the new assembly
> > plugin. There are still some outstanding issues (though not as many as
> > jira would have you believe; they just need tests), but I think we're
> > at around 95-99% backward compatibility and the new features seem to
> > be working well. It's been just sitting in SVN for quite awhile now,
> > and many people are using it directly from there. I'd like to provide
> > better support for those people, and start getting more feedback on
> > exactly what's still broken.
> >
> > The change list is pretty large, but is mainly concerned with
> > refactoring the plugin away from the old monolithic approach to one
> > that uses phases to handle the different descriptor sections, along
> > with common task classes to handle behavior shared between phases.
> >
> > Road Map:
> >
> > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126&style
> >Name=Html&version=12617
> >
> >
> > Tag:
> >
> > http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plug
> >in-2.2-beta-1
> >
> >
> > Staging repository:
> >
> > http://people.apache.org/~jdcasey/stage/repo<http://people.apache.org/
> >%7Ejdcasey/stage/repo>
> >
> > So, let's try 72h +1/+0/-1. Please cast your votes!
> >
> > Here's my +1.
> >
> > -john
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194
> daniel.kulp@iona.com
> http://www.dankulp.com/blog
>
> ---------------------------------------------------------------------
> 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: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1
Posted by Daniel Kulp <dk...@apache.org>.
+1
Dan
On Friday 06 April 2007 10:55, John Casey wrote:
> Hi everyone,
>
> This is the third attempt, after fixing:
>
> *
> http://jira.codehaus.org/browse/MASSEMBLY-194<http://jira.codehaus.org
>/browse/MASSEMBLY-155>
>
> This bugfix actualy adds a new flag to the dependencySet, called
> useTransitiveFiltering, which allows you to enable filtering by
> matching a given pattern against the transitive dependency path of
> the given artifact (in addition to all the other ways). By default,
> this is disabled (useTransitiveFiltering == false), in order to
> preserve backward compat with version 2.1.
>
> So, let's try this one more time:
>
> I wanted to call a vote to release a beta version of the new assembly
> plugin. There are still some outstanding issues (though not as many as
> jira would have you believe; they just need tests), but I think we're
> at around 95-99% backward compatibility and the new features seem to
> be working well. It's been just sitting in SVN for quite awhile now,
> and many people are using it directly from there. I'd like to provide
> better support for those people, and start getting more feedback on
> exactly what's still broken.
>
> The change list is pretty large, but is mainly concerned with
> refactoring the plugin away from the old monolithic approach to one
> that uses phases to handle the different descriptor sections, along
> with common task classes to handle behavior shared between phases.
>
> Road Map:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126&style
>Name=Html&version=12617
>
>
> Tag:
>
> http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plug
>in-2.2-beta-1
>
>
> Staging repository:
>
> http://people.apache.org/~jdcasey/stage/repo<http://people.apache.org/
>%7Ejdcasey/stage/repo>
>
> So, let's try 72h +1/+0/-1. Please cast your votes!
>
> Here's my +1.
>
> -john
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1
Posted by Brett Porter <br...@apache.org>.
-1 (just a vote, not a veto)
I've found 2 backwards incompatibilities that affect its usability in
my build:
- dependencies are unpacked into a subdirectory with their artifactId
where they weren't before (this may be correct behaviour where before
it was a bug, just needs to be checked)
- the repository building capabilities appear not to be working at all
Are either of these already in JIRA, or should I file them? I
couldn't see them.
Thanks again for your persistence :)
- Brett
On 07/04/2007, at 12:55 AM, John Casey wrote:
> Hi everyone,
>
> This is the third attempt, after fixing:
>
> * http://jira.codehaus.org/browse/MASSEMBLY-194<http://
> jira.codehaus.org/browse/MASSEMBLY-155>
>
> This bugfix actualy adds a new flag to the dependencySet, called
> useTransitiveFiltering, which allows you to enable filtering by
> matching a
> given pattern against the transitive dependency path of the given
> artifact
> (in addition to all the other ways). By default, this is disabled
> (useTransitiveFiltering == false), in order to preserve backward
> compat with
> version 2.1.
>
> So, let's try this one more time:
>
> I wanted to call a vote to release a beta version of the new assembly
> plugin. There are still some outstanding issues (though not as many
> as jira
> would have you believe; they just need tests), but I think we're at
> around
> 95-99% backward compatibility and the new features seem to be
> working well.
> It's been just sitting in SVN for quite awhile now, and many people
> are
> using it directly from there. I'd like to provide better support
> for those
> people, and start getting more feedback on exactly what's still
> broken.
>
> The change list is pretty large, but is mainly concerned with
> refactoring
> the plugin away from the old monolithic approach to one that uses
> phases to
> handle the different descriptor sections, along with common task
> classes to
> handle behavior shared between phases.
>
> Road Map:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?
> projectId=11126&styleName=Html&version=12617
>
>
> Tag:
>
> http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-
> plugin-2.2-beta-1
>
>
> Staging repository:
>
> http://people.apache.org/~jdcasey/stage/repo<http://
> people.apache.org/%7Ejdcasey/stage/repo>
>
> So, let's try 72h +1/+0/-1. Please cast your votes!
>
> Here's my +1.
>
> -john
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org