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 [EMAIL PROTECTED] wrote:
I think if we just change the plugin resolution so that it doesn't
assume RELEASE if no version is set, it should
+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
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 [EMAIL PROTECTED] wrote:
Brian E. Fox schrieb:
This is a MUCH bigger problem than we seem to recognize. Who
+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)
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
+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 [EMAIL PROTECTED] wrote:
Hi everyone,
This is the third attempt, after fixing:
* http://jira.codehaus.org/browse/MASSEMBLY-194
+1 for that!
On 4/11/07, Geoffrey De Smet [EMAIL PROTECTED] 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
together?
-Original Message-
From: Arik Kfir [mailto:[EMAIL PROTECTED]
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
On 4/12/07, Brian E. Fox [EMAIL PROTECTED] 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
I never use either to be honest so I'm not actually sure what the
difference is.
-Original Message-
From: Barrie Treloar [mailto:[EMAIL PROTECTED]
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
+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 [EMAIL PROTECTED] wrote:
+1
Dan
On Friday 06 April 2007 10:55, John Casey wrote:
Hi
#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
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.
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 [EMAIL
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
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
: [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-194http://jira.codehaus.org/b
rowse/MASSEMBLY-155
This bugfix actualy adds a new flag to the dependencySet, called
useTransitiveFiltering
to
fix.
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
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
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
-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)
+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-194http://jira.codehaus.org
/browse/MASSEMBLY-155
This bugfix actualy adds a new flag to the dependencySet, called
Hi everyone,
This is the third attempt, after fixing:
*
http://jira.codehaus.org/browse/MASSEMBLY-194http://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
22 matches
Mail list logo
