Right I get that. That would be pretty annoying.
Maybe instead of a parent POM, an import facility could be used
that can
grab the same centralized POM (Multiple-inheritance almost :-).
To John's comment, I don't see this being a big offline challenge
as this
centralized POM would be a released 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]
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
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 and it won't change
often. All our projects inherit from that one, it will be a pain to
update
everything every time we would want to upgrade some plug-ins.
Stéphane
On 4/12/07, Hayes, Peter <[EMAIL PROTECTED]> wrote:
I'd like to give my 2 cents on this issue.
Would it be possible to maintain a super POM on repo1 that
contains a
vetted set of plugin versions and then version that POM
appropriately
based on new releases of core plugins? Then it would simply 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 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 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 specified, then latest.
For a released build, I want the pom to be transformed and fully
locked down so that the build is reproducible. And I don't
want to
do that manually.
I would expect that my snapshot builds to be exactly the same as
the
eventual release build for that version. The last thing I need is
release to decide for me which versions to use. I do want to do it
manually, because I want to try out each new plugin before I
bless it
and allow it into the build process for the rest of the team.
I've had
too many occurrences where a plugin change breaks my build (I'm ok
with that, it's necessary for forward progress). By manually
vetting a
plugin, it gives me a chance to make any adjustments needed.
It's no different than how we upgrade Maven itself: I have used
enforcer to lock my build to 2.0.5 until I can get all the depMgt
straightened out and then I will move everyone forward.
-------------------------------------------------------------------
--
To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]
-------------------------------------------------------------------
--
To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional
commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
