On 14-Jan-08, at 9:18 AM, Mark Hobson wrote:
On 03/01/2008, Brett Porter <[EMAIL PROTECTED]> wrote:
I said intended, because from memory I wasn't sure if it was still
commented out :)
I implemented release POMs in maven-release-plugin 2.0-beta-6, see:
http://jira.codehaus.org/browse/MRELEAS
On 03/01/2008, Brett Porter <[EMAIL PROTECTED]> wrote:
> I said intended, because from memory I wasn't sure if it was still
> commented out :)
I implemented release POMs in maven-release-plugin 2.0-beta-6, see:
http://jira.codehaus.org/browse/MRELEASE-177
Mark
--
I said intended, because from memory I wasn't sure if it was still
commented out :)
The problem with the use of this POM for release:perform is that it
will be deployed into the repository - and that's not what you want.
You then get the resolved dependencies instead of the declared ones,
On Jan 1, 2008 1:28 AM, Brett Porter <[EMAIL PROTECTED]> wrote:
> FWIW, This is precisely the functionality that the
> "generateReleasePoms" flag of the release plugin was intended to
> provide.
>
"Intended to provide"? Does it actually provide it?
The documentation for this flag seems a bit inc
FWIW, This is precisely the functionality that the
"generateReleasePoms" flag of the release plugin was intended to
provide.
(Happy New Year from Aus. everyone :)
Cheers,
Brett
On 31/12/2007, at 11:21 PM, Simon Kitching wrote:
Hi All,
John Casey wrote:
Hi everyone,
I'd like to make
Hi All,
John Casey wrote:
>
> Hi everyone,
>
> I'd like to make sure we're all on the same page with the plugin
> auto-version resolution stuff that we've been discussing lately (on the
> assembly-plugin vote thread, for one thing). I think it's clear that we
> cannot continue to allow Maven t
> POM...
>
>
>
>
> -----Original Message-
> From: Hervé BOUTEMY [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 01, 2007 1:36 PM
> To: Maven Developers List
> Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1
>
> Le mardi 1 mai 2007, T
x27;s
good at and keep track of these bits. We will just say we want it to
work :-)
Jason.
hey can be dynamic - specified in the settings file or top level
POM...
-Original Message-
From: Hervé BOUTEMY [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 01, 2007 1:36 PM
To: Maven De
settings file or top level POM...
-Original Message-
From: Hervé BOUTEMY [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 01, 2007 1:36 PM
To: Maven Developers List
Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1
Le mardi 1 mai 2007, Tomasz Pik a écrit :
>
Le mardi 1 mai 2007, Tomasz Pik a écrit :
> On 5/1/07, Hervé BOUTEMY <[EMAIL PROTECTED]> wrote:
> > Le mardi 1 mai 2007, Jerome Lacoste a écrit :
> > > Maybe there could be an easy way to let users use the latest ? maybe
> > > something like
> > > mvn -L ... ( L for latest)
> > > that would ign
On 5/1/07, Hervé BOUTEMY <[EMAIL PROTECTED]> wrote:
Le mardi 1 mai 2007, Jerome Lacoste a écrit :
> Maybe there could be an easy way to let users use the latest ? maybe
> something like
> mvn -L ... ( L for latest)
> that would ignore all specified versions, without requiring a POM
> change ?
On 5/1/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
How on earth would you ever debug the inevitable issues when you suddenly
upgrade to all new versions of plugins (and worse dependencies?)?
because you don't do it "suddenly", you would do it continuously.
Jerome
: Remove auto-resolution of plugin versions from Maven 2.1
Le mardi 1 mai 2007, Jerome Lacoste a écrit :
> Maybe there could be an easy way to let users use the latest ? maybe
> something like
> mvn -L ... ( L for latest)
> that would ignore all specified versions, without requiring a P
Le mardi 1 mai 2007, Jerome Lacoste a écrit :
> Maybe there could be an easy way to let users use the latest ? maybe
> something like
> mvn -L ... ( L for latest)
> that would ignore all specified versions, without requiring a POM
> change ? Maybe too radical.
such a LATEST option would be very
On 4/11/07, John Casey <[EMAIL PROTECTED]> wrote:
Hi everyone,
I'd like to make sure we're all on the same page with the plugin
auto-version resolution stuff that we've been discussing lately (on the
assembly-plugin vote thread, for one thing). I think it's clear that we
cannot continue to allow
Jose Alberto Fernandez wrote:
>
> I thought one of the main arguments in all this discussion is to make
> things simple and easy for users. At least those were the comments against
> forcing everyone to explicitly set versions for everything. The bundle
> will free every single user of having t
Brian E. Fox wrote:
>
> Everyone keeps referring to bundles that "are known to work together."
> Come someone produce an example of plugins that are incompatible with
> each other? I haven't seen this and I'm not even sure it's possible
> given that plugins can't communicate or even know about
Wayne Fay wrote:
>
> On 4/21/07, Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote:
>> So if I say BETA then no alpha bundle (a bundle
>> containing alpha software) will be selected.
>
> Who exactly decides what the quality is for a given release? Outside
> of a handful (literally) of major ap
I thought one of the main arguments in all this discussion is to make things
simple and easy for users. At least those were the comments against forcing
everyone to explicitly set versions for everything. The bundle will free
every single user of having to go finding out what version of what to us
Brian E. Fox wrote:
>
> Everyone keeps referring to bundles that "are known to work together."
> Come someone produce an example of plugins that are incompatible with
> each other? I haven't seen this and I'm not even sure it's possible
> given that plugins can't communicate or even know about e
"Can't you have a plug-in that generates some file to be consumed by
another plugin? It may not be the most orthodox usage but definitely a
possibility.
Just because you do not have one now, it does not mean it cannot happen.
The plug-in may not talk to each other but they may use different
versi
>> I haven't seen this and I'm not even sure it's possible given that
>> plugins can't communicate or even know about each other.
>XDoclet plugin depends on Antrun plugin 1.0. And the dep is declared as
*jar* dependency
>(relying on the fact, that M2 cannot distinguish it). This is the real
cu
On 23 Apr 07, at 8:57 AM 23 Apr 07, Jörg Schaible wrote:
Hi Brian,
Brian E. Fox wrote on Monday, April 23, 2007 2:42 PM:
Everyone keeps referring to bundles that "are known to work
together."
Come someone produce an example of plugins that are incompatible with
each other?
Annoying: http
On 23 Apr 07, at 8:42 AM 23 Apr 07, Brian E. Fox wrote:
Everyone keeps referring to bundles that "are known to work together."
Come someone produce an example of plugins that are incompatible with
each other? I haven't seen this and I'm not even sure it's possible
given that plugins can't commu
Hi Brian,
Brian E. Fox wrote on Monday, April 23, 2007 2:42 PM:
> Everyone keeps referring to bundles that "are known to work together."
> Come someone produce an example of plugins that are incompatible with
> each other?
Annoying: http://jira.codehaus.org/browse/MOJO-641
> I haven't seen this
Everyone keeps referring to bundles that "are known to work together."
Come someone produce an example of plugins that are incompatible with
each other? I haven't seen this and I'm not even sure it's possible
given that plugins can't communicate or even know about each other.
I personally think a
On 22 Apr 07, at 11:09 PM 22 Apr 07, Wayne Fay wrote:
On 4/21/07, Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote:
So if I say BETA then no alpha bundle (a bundle
containing alpha software) will be selected.
Who exactly decides what the quality is for a given release?
Dead on. All this wi
Wayne Fay wrote:
>
> On 4/21/07, Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote:
>> So if I say BETA then no alpha bundle (a bundle
>> containing alpha software) will be selected.
>
> Who exactly decides what the quality is for a given release? Outside
> of a handful (literally) of major apps
Wendy Smoak-3 wrote:
>
> On 4/21/07, Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote:
>
>> Well, having the documentation not reflecting the released plugins but
>> SNAPSHOTs is not helpful to any user.
>
> We're discussing this now in a different thread. Please add your
> comments there if
On 4/21/07, Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote:
So if I say BETA then no alpha bundle (a bundle
containing alpha software) will be selected.
Who exactly decides what the quality is for a given release? Outside
of a handful (literally) of major apps/projects (Linux kernel and
Apach
, Brian E. Fox wrote:
I wrote this up here: http://jira.codehaus.org/browse/MNG-2945
-Original Message-
From: Nigel Magnay [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 12, 2007 2:42 PM
To: Maven Developers List
Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1
Here&#
On 12/04/2007, at 8:49 PM, Wayne Fay wrote:
I'd also suggest that it might be helpful for someone to track the
fundamental reason(s) behind emails to the Users list for a period of
time (1-2 weeks) and then pick the top recurring reasons, and add them
to the FAQ. It would be nice if there was a
On 12/04/2007, at 4:15 PM, John Casey wrote:
1. Locking down on release is dangerous IMO, because it implies
that you
might be making a change to the build behavior at release time.
I don't think that was the intent. It was intended to capture exactly
what you used at release time. The pr
On 4/21/07, Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote:
Well, having the documentation not reflecting the released plugins but
SNAPSHOTs is not helpful to any user.
We're discussing this now in a different thread. Please add your
comments there if you have a preference.
http://www.nabbl
Wayne Fay wrote:
>
> I wish I knew how to properly handle the issue of what I will call
> laziness wrt reading and using documentation on the part of users. It
> might be helpful to add a lot more things to the FAQ (including
> comments about web proxies with a link to the "configuring proxy" pa
On 4/17/07, Kevin Menard <[EMAIL PROTECTED]> wrote:
support newer releases of external software. At least in the case of
Selenium, the authors know that they're released version is broken and
their response is to just use SNAPSHOT. That's the sort of scenario I'd
like to see avoided if possible
lto:[EMAIL PROTECTED]
> Sent: Thursday, April 12, 2007 5:24 PM
> To: Maven Developers List
> Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1
>
> I'm interested to know which snapshots bit you guys so hard?
> Was it a [set of] internal snapshots, or
Brett Porter wrote:
I think it's more complicated than just removing that.
Firstly, large numbers of command line plugins will stop working.
Secondly, we need to provide a solution for implied plugins (we can set
the version in the lifecycle and then let the user give pluginManagement
to over
On 4/14/07, ArneD <[EMAIL PROTECTED]> wrote:
>> 2. Many users don't want to make a distinction between Maven itself
>> and the
>> Maven core plugins (compile, jar, ...).
>
> This also not true in my experience. Core plugins are not distributed
> with Maven because we have consciously decoupled th
On 13 Apr 07, at 11:33 AM 13 Apr 07, ArneD wrote:
Jason,
thanks a lot for your answer.
I did not want to suggest that every Maven user should be forced to
work
decoupled from repo1. But currently it is much harder than it
should be, and
this should be improved.
I agree. We really need
Jason,
thanks a lot for your answer.
I did not want to suggest that every Maven user should be forced to work
decoupled from repo1. But currently it is much harder than it should be, and
this should be improved. And I do agree that the separation of the Maven
core and the plugins has its benefit
On 4/13/07, ArneD <[EMAIL PROTECTED]> wrote:
To adress these issues, may I suggest the following:
- Build Maven distributions that include a super POM that declares the
latest stable(!) version of all core Maven plugins (i.e. the plugins hosted
on maven.apache.org).
That won't work. You could
ogy.
Peter
-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 12, 2007 10:10 AM
To: Maven Developers List
Subject: RE: Remove auto-resolution of plugin versions from Maven
2.1
Same here.
-Original Message-
From: Stephane Nicoll [mailto:[EMAI
On 13 Apr 07, at 5:10 AM 13 Apr 07, ArneD wrote:
Hi everybody,
from a corporate user's point of view, I believe, the following
points are
important:
1. Corporate users want to be completely decoupled from what's
happening on
repo1.
No they don't. In my experience they have wanted to
eleased version that could safely be cached
>> in a
>> local repository, like any other artifact, i.e. it would follow the
>> snapshot / release methodology.
>>
>> Peter
>>
>> -Original Message-
>> From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Hi everybody,
from a corporate user's point of view, I believe, the following points are
important:
1. Corporate users want to be completely decoupled from what's happening on
repo1. Many even don't want to proxy repo1 but instead manage their own
repository. This is especially true for build ar
I couldnt agree more with the sentiments that code in *all its guises* must
be explcitly managed. you don't compile arbitrary code, don't use arbitrary
compilers, don't link against arbitrary libraries... arbitrary bad. Build
scripts are code, christ even my shell is a dependency to be managed
(mi
This pretty much describes our world too.
And I couldnt agree more with the sentiments that code in *all its guises*
must be explcitly managed. you don't compile arbitrary code, don't use
arbitrary compilers, don't link against arbitrary libraries... arbitrary
bad. Build scripts are code, christ
ch). People would then just go get the code anyway.
>
> -Original Message-----
> From: Kevin Menard [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 12, 2007 1:09 PM
> To: Maven Developers List
> Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1
>
> R
On 4/13/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
Here's how I deal with instances where I need a snapshot plugin in my
corp build:
1. Checkout the code for the snapshot.
2. Build it, changing the version to something like
2.0-[companyname]-svnrev
3. If I have to patch the source at all, I take
> -Original Message-
> From: Kevin Menard [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 12, 2007 1:09 PM
> To: Maven Developers List
> Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1
>
> Right.
>
> My point is that regardless of w
RE: Remove auto-resolution of plugin versions from Maven 2.1
Right.
My point is that regardless of what the original intention may have
been, the current process facilitates laziness via SNAPSHOTs. Without
them, incremental builds would be necessary, which would give fixed
version numbers with know
I wrote this up here: http://jira.codehaus.org/browse/MNG-2945
-Original Message-
From: Nigel Magnay [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 12, 2007 2:42 PM
To: Maven Developers List
Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1
>
> Here's
Yes I also agree this would be handy at times.
-Original Message-
From: Wayne Fay [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 12, 2007 2:53 PM
To: Maven Developers List
Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1
Sounds like a great idea for a very useful
Sounds like a great idea for a very useful plugin. I'm sure many of us
have followed this same pattern when it comes time to do a release
which utilizes snapshot plugins or artifacts.
Wayne
On 4/12/07, Nigel Magnay <[EMAIL PROTECTED]> wrote:
>
> Here's how I deal with instances where I need a s
ly do
> > internally but if it is maintained on repo1, it would save a lot of work
> > for a lot of people.
> >
> > Peter
> >
> > -Original Message-
> > From: Brian E. Fox [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, April 11, 2007 10:
Here's how I deal with instances where I need a snapshot plugin in my
corp build:
1. Checkout the code for the snapshot.
2. Build it, changing the version to something like
2.0-[companyname]-svnrev
3. If I have to patch the source at all, I take the whole thing and put
it in my svn. If not, then
y be an
> > > inclusion of a specific parent version in a project POM that would
> > > control which plugins to take. I think this is what people probably
do
> > > internally but if it is maintained on repo1, it would save a lot of
work
> > > for a lot of peopl
I am just a Maven user with very little understanding of Maven internals, but
isn't it possible to have a date/timestamp attribute affiliated with the
? Maybe like a ?
Such a timestamp could be used to force a lockdown at that time so all
developers share a common set of functionality. RELEAS
is what people probably do
> > internally but if it is maintained on repo1, it would save a lot of work
> > for a lot of people.
> >
> > Peter
> >
> > -Original Message-
> > From: Brian E. Fox [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday,
etc, but it is most
> definitely stable and reproducible. (even if our repo disappears).
>
> -Original Message-
> From: Kevin Menard [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 12, 2007 12:50 PM
> To: Maven Developers List
> Subject: RE: Remove auto-resolution of
Sent: Thursday, April 12, 2007 12:50 PM
To: Maven Developers List
Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1
A bit of a departure from the discussion, but still related . . .
It may be worthwhile to rethink the whole SNAPSHOT system, too, then.
Way too many plugins and depen
x [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 12, 2007 11:08 AM
> To: Maven Developers List
> Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1
>
> John, I think you've hit the nail on the head here. If you
> look at it this way, your plugins used are
Remove auto-resolution of plugin versions from Maven 2.1
Same here.
-Original Message-
From: Stephane Nicoll [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 12, 2007 9:02 AM
To: Maven Developers List
Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1
Won't work every
opers List
Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1
Same here.
-Original Message-
From: Stephane Nicoll [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 12, 2007 9:02 AM
To: Maven Developers List
Subject: Re: Remove auto-resolution of plugin versions from Maven
dency, the same should be true for plugins.
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 12, 2007 11:00 AM
To: Maven Developers List
Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1
One thing I wanted to add:
To me, it's c
t; inclusion of a specific parent version in a project POM that would
> > control which plugins to take. I think this is what people probably
> do
> > internally but if it is maintained on repo1, it would save a lot of
> work
> > for a lot of people.
> >
> > Pet
sion of a specific parent version in a project POM that would
> control which plugins to take. I think this is what people probably do
> internally but if it is maintained on repo1, it would save a lot of work
> for a lot of people.
>
> Peter
>
> -----Original Message-
> From
Same here.
-Original Message-
From: Stephane Nicoll [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 12, 2007 9:02 AM
To: Maven Developers List
Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1
Won't work every time.
We have a corporate pom, it's pretty m
sday, April 11, 2007 10:40 PM
To: Maven Developers List
Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1
>If I need a specific version (usual to workaround a known issue) then
>I specify it in the the pom. Otherwise I want the latest.
This is the current problem, where b
2007 10:40 PM
To: Maven Developers List
Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1
>If I need a specific version (usual to workaround a known issue) then
>I specify it in the the pom. Otherwise I want the latest.
This is the current problem, where builds ar
Carlos Sanchez wrote:
>
> I think every maven release should use a defined set of plugin versions.
> That would be reproducible and close to what it's happening now.
>
Sounds good. So for the compile plugin if I don't specify a version I get
the default that was tested as part of the release
Carlos Sanchez wrote:
I think every maven release should use a defined set of plugin
versions. That would be reproducible and close to what it's happening
now.
I can't really agree with this; if maven provides a set of default
plugin versions, people will continue to not specify explicit versi
I thought release POMs were meant to resolve the issue of reproducible builds?
Theoretically, when generateReleasePoms=true, release:perform will
write an auxiliary POM with resolved versions for all plugins,
dependencies, etc. that Maven uses in preference to the normal
transformed POM. I say t
I Agree.
Minimum configuration should be enough for the common use cases. But
if your build fails with the minimum configuration, then that's the
time you add in other configurations.
IMHO, it's just like the dependency mechanism. A typical user would
only have to specify the artifacts he / she
nection between javax.* and the plugins?
-Original Message-
From: Wayne Fay [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 11, 2007 4:10 PM
To: Maven Developers List
Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1
Strongly agree with Carlos and Dan. We already have
>If I need a specific version (usual to workaround a known issue) then
>I specify it in the the pom. Otherwise I want the latest.
This is the current problem, where builds are done with undetermined
versions. (ie the version for dev a might not match dev b)
>For snapshot builds if I will use spec
I don't see the connection between javax.* and the plugins?
-Original Message-
From: Wayne Fay [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 11, 2007 4:10 PM
To: Maven Developers List
Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1
Strongly agree with Carlo
On 4/11/07, Barrie Treloar <[EMAIL PROTECTED]> wrote:
On 4/12/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> I think every maven release should use a defined set of plugin
> versions. That would be reproducible and close to what it's happening
> now.
>
> Making the user list all plugins it's gon
On 4/12/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
I think every maven release should use a defined set of plugin
versions. That would be reproducible and close to what it's happening
now.
Making the user list all plugins it's gonna be killer for newbies.
If I need a specific version (usual
On 4/11/07, John Casey <[EMAIL PROTECTED]> wrote:
Actually, the "unwittingly try and build it with 2.1" scenario is a case
where it would be nice to have a prereq on maven < 2.1 in the POM. I don't
think that 2.0.x supports that sort of thing in the section,
but I imagine the enforcer-plugin wou
Strongly agree with Carlos and Dan. We already have enough troubles on
M-U with web proxies and javax.* artifacts not available in Central,
we really don't need to add to the troubles by requiring users to
specify every single plugin.
Wayne
On 4/11/07, Dan Tran <[EMAIL PROTECTED]> wrote:
I have
I have to agree with Carlos, it is a killer for newbies, and it means slow
adoption
But speaking from my experience, I ended up to specify all plugin versions
to reduce ambiguities.
-D
On 4/11/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
I think every maven release should use a defined set
I think every maven release should use a defined set of plugin
versions. That would be reproducible and close to what it's happening
now.
Making the user list all plugins it's gonna be killer for newbies.
On 4/11/07, John Casey <[EMAIL PROTECTED]> wrote:
Actually, the "unwittingly try and build
Actually, the "unwittingly try and build it with 2.1" scenario is a case
where it would be nice to have a prereq on maven < 2.1 in the POM. I don't
think that 2.0.x supports that sort of thing in the section,
but I imagine the enforcer-plugin would do it.
I think we should write something into 2
On 11 Apr 07, at 1:04 PM 11 Apr 07, Brett Porter wrote:
I think it's more complicated than just removing that.
Firstly, large numbers of command line plugins will stop working.
For anything specified in POM the version needs to be specified.
Anything that is useful and required for a buil
+1
Being explicit is good.
Jason.
On 11 Apr 07, at 12:54 PM 11 Apr 07, John Casey wrote:
Hi everyone,
I'd like to make sure we're all on the same page with the plugin
auto-version resolution stuff that we've been discussing lately (on
the
assembly-plugin vote thread, for one thing). I thin
I think it's more complicated than just removing that.
Firstly, large numbers of command line plugins will stop working.
Secondly, we need to provide a solution for implied plugins (we can
set the version in the lifecycle and then let the user give
pluginManagement to override it, but I'd li
Here's how I see it in 2.1:
Command Line Invocation:
-No change. That is if a version is specified in the POM or Plugin
Management, use that. Else, use RELEASE. If a fully qualified plugin
name is used in place of the prefix, use that (ie
org.apache.maven.plugins.maven-dependency-plugin:2.0-alpha-
On 4/11/07, Brett Porter <[EMAIL PROTECTED]> wrote:
I think it's more complicated than just removing that.
Firstly, large numbers of command line plugins will stop working.
Secondly, we need to provide a solution for implied plugins (we can
set the version in the lifecycle and then let the user
90 matches
Mail list logo
