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
ith
the checked-in explicit-dependencies file to create a repeatable
build.
The separate dependencies file seems useful as documentation in its
own
right, rather like the "dependencies report" that can be generated for
websites.
Regards,
Simon
--
View this message in context:
http:
dependency resolution. However people can also choose to invoke maven with
the checked-in explicit-dependencies file to create a repeatable build.
The separate dependencies file seems useful as documentation in its own
right, rather like the "dependencies report" that can be generated fo
> 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
l versions are set in the pom, then we
are going to need an easy way to version bump. Perhaps we need something
like "mvn help:effective-pom" does now, or pehaps a way of listing all newer
available plugins.
--
View this message in context:
http://www.nabble.com/Remove-auto-resol
on cobertura v1.7, but
it has a different bug of it's own. Thus neither version combination is a
"known good set".
--
View this message in context:
http://www.nabble.com/Remove-auto-resolution-of-plugin-versions-from-Maven-2.1-tf3560617s177.html#a10164293
Se
builds and labels would be too big for
maven right now, so a simpler approach in needed. Perhaps a simple way
could be found to promote alpha and beta releases to final once enough
testing has been done.
Ultimately it's a problem of governance, and with such a widely dispersed
leadersh
a management-POM if that sounds better, which is basically limited
to contain the above mentioned elements.
That should not be that difficult or complex to understand/implement.
Jose Alberto
--
View this message in context:
http://www.nabble.com/Remove-auto-resolution-of-plugin-versions-
nk they work correctly.
Well actually it does not work correctly, but that is an issue for a
different thread.
Jose Alberto
--
View this message in context:
http://www.nabble.com/Remove-auto-resolution-of-plugin-versions-from-Maven-2.1-tf3560617s177.html#a10141305
Sent from
"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
provide a tool that allows listing the transitive closure
of dependencies of a bundle so that someone can check that no sneaky alpha
code is getting pull in. But at the end of the day someone needs to take
responsibility, just like you do when declaring a new Maven release to be of
RELEASED status.
H
e definition of the descriptor has no info on what is available on
which version. It becomes a huge trial and error exercise.
Will try following the discussion on the other thread, thanks.
Jose Alberto
--
View this message in context:
http://www.nabble.com/Remove-auto-resolution-of-plugin-ve
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
too.
So there you are some food for thought from a concern user...
Jose Alberto
--
View this message in context:
http://www.nabble.com/Remove-auto-resolution-of-plugin-versions-from-Maven-2.1-tf3560617s177.html#a10119790
Sent from the Maven D
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
r own aren't
available.
- Arne
--
View this message in context: http://www.nabble.com/Remove-auto-
resolution-of-plugin-versions-from-Maven-2.1-
tf3560617s177.html#a9981105
Sent from the Maven Developers mailing list archive at Nabble.com.
---
all Maven core plugins (in
>> form of
>> a pre-filled local repository, for example) in the latest stable
>> version
>>
>
> That's entirely possible, and we could definitely do something like
> that if was deemed something of value by users.
>
>
I
ot sure I follow but I don't see how it will fix the problem.
Stéphane
Regards
- Arne
--
View this message in context:
http://www.nabble.com/Remove-auto-resolution-of-plugin-versions-from-Maven-2.1-tf3560617s177.html#a9975501
Sent from the Maven Developers mailing list
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
t stable
version
That's entirely possible, and we could definitely do something like
that if was deemed something of value by users.
Jason.
Regards
- Arne
--
View this message in context: http://www.nabble.com/Remove-auto-
resolution-of-plugin-versions-from-Maven-2.1-
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]
View this message in context:
http://www.nabble.com/Remove-auto-resolution-of-plugin-versions-from-Maven-2.1-tf3560617s177.html#a9975501
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [
;s my +1.
>>
>> -john
>
>
> -----------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.c
ection
> trying to figure out if package 2.0.6 contains Assembly 2.1 or
> 2.2-alpha-1.
>
> -Original Message-----
> From: John Casey [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 11, 2007 12:55 PM
> To: Maven Developers List
> Subject: Remove auto-resolution of plugin v
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
rsion overrides should
still be allowed.
Just a thought. Likely I am missing something simple in all this.
John Eichelsdorfer
--
View this message in context:
http://www.nabble.com/Remove-auto-resolution-of-plugin-versions-from-Maven-2.1-tf3560617s177.html#a9965491
Sent from the Maven Devel
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
y to all.
Thanks
David
--
View this message in context:
http://www.nabble.com/Remove-auto-resolution-of-plugin-versions-from-Maven-2.1-tf3560617s177.html#a9955794
Sent from the Maven Developers mailing list archive at Nabble.com.
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
anyway as
soon as a plugin gets release. Not to mention the extra indirection
trying to figure out if package 2.0.6 contains Assembly 2.1 or
2.2-alpha-1.
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 11, 2007 12:55 PM
To: Maven Developers List
Subject:
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
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 to resolve RELEASE or LATEST meta-versions
f
91 matches
Mail list logo
