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
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:
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
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,
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 to
-resolution of plugin versions from Maven 2.1
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
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
: 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 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
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 ? Maybe
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 ignore all
- 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 Developers List
Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1
Le mardi 1 mai 2007, Tomasz Pik a écrit
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 Developers List
Subject: Re: Remove auto-resolution of plugin
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
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 each
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 to go
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 you have a
Wayne Fay wrote:
On 4/21/07, Jose Alberto Fernandez [EMAIL PROTECTED] wrote:
So if I say qualityBETA/quality 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
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 qualityBETA/quality then no alpha bundle (a bundle
containing alpha software) will be selected.
Who exactly decides what the quality is for a given release?
Dead
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
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 and
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
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:
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
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
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 each
Wayne Fay wrote:
On 4/21/07, Jose Alberto Fernandez [EMAIL PROTECTED] wrote:
So if I say qualityBETA/quality 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
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
, 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's
On 4/21/07, Jose Alberto Fernandez [EMAIL PROTECTED] wrote:
So if I say qualityBETA/quality 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
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 page
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.
, 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 were they snapshots
from Maven or some other OSS project that you depend
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.
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 the
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
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
-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:[EMAIL PROTECTED]
Sent
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
[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:[EMAIL PROTECTED]
Sent: Thursday, April 12, 2007 9:02 AM
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
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
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
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
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
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 of
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 are done
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 are done with undetermined
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 much stable
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:40 PM
To: Maven Developers List
Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1
for a lot of people.
Peter
-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 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
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 critical to view your
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 2.1
Won't
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 time.
We have a corporate pom
]
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 no different than
dependencies. It's very
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 dependencies sit in a SNAPSHOT
[mailto:[EMAIL PROTECTED]
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
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 are done
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
version? Maybe like a version-timestamp?
Such a timestamp could be used to force a lockdown at that time so all
developers share a common set
for a lot of people.
Peter
-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 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
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
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:40 PM
To: Maven Developers List
Subject: RE: Remove auto-resolution of plugin versions from
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
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
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 how I deal
-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 known binaries
Developers List
Subject: 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
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
Developers List
Subject: 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
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
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
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
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
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
+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
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
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 prerequisites section,
but I imagine the enforcer-plugin would do it.
I think we should write
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
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
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
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 prerequisites section,
but I imagine the
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, 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 gonna be
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 Carlos
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
.* 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 enough troubles on
M-U with web
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
87 matches
Mail list logo
