Remove auto-resolution of plugin versions from Maven 2.1

[John Casey <ca...@gmail.com>]

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
for plugins any more. I'd actually argue that this is bad practice for ANY
artifact that is to be resolved, including site skins, etc. since it kills
our ability to deprecate features.

I'd like to completely remove this from the DefaultPluginManager in trunk,
so we can start moving away from this practice immediately.

I guess this is an informal vote on the subject, but I wanted to get
everyone's opinions before I move on it, since it's a fairly important
change.

Here's my +1.

-john

Re: Remove auto-resolution of plugin versions from Maven 2.1

[jallen <jo...@hotmail.com>]

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
(mid-90s multi-platform C++ coming back to haunt me). As others have said I
think migration and upgrade scenarios are better supported by tools, plugins
and docs, not inference and discovery (and by this i mean a plugin that
tells you what is potentially available for upgrade)

J 

Jason van Zyl-2 wrote:
> 
> +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 think it's clear  
>> that we
>> cannot continue to allow Maven to resolve RELEASE or LATEST meta- 
>> versions
>> for plugins any more. I'd actually argue that this is bad practice  
>> for ANY
>> artifact that is to be resolved, including site skins, etc. since  
>> it kills
>> our ability to deprecate features.
>>
>> I'd like to completely remove this from the DefaultPluginManager in  
>> trunk,
>> so we can start moving away from this practice immediately.
>>
>> I guess this is an informal vote on the subject, but I wanted to get
>> everyone's opinions before I move on it, since it's a fairly important
>> change.
>>
>> Here's my +1.
>>
>> -john
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Remove-auto-resolution-of-plugin-versions-from-Maven-2.1-tf3560617s177.html#a9970397
Sent from the Maven Developers mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Jason van Zyl <ja...@maven.org>]

+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 think it's clear  
> that we
> cannot continue to allow Maven to resolve RELEASE or LATEST meta- 
> versions
> for plugins any more. I'd actually argue that this is bad practice  
> for ANY
> artifact that is to be resolved, including site skins, etc. since  
> it kills
> our ability to deprecate features.
>
> I'd like to completely remove this from the DefaultPluginManager in  
> trunk,
> so we can start moving away from this practice immediately.
>
> I guess this is an informal vote on the subject, but I wanted to get
> everyone's opinions before I move on it, since it's a fairly important
> change.
>
> Here's my +1.
>
> -john


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Barrie Treloar <ba...@gmail.com>]

On 4/14/07, ArneD <pu...@degenring.de> 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 lifecycle of
> > plugins from the core because any plugins we house here may, in fact,
> > be release two or three times between major releases of Maven and
> > binding these versions in the core would be a bad idea.
> >
>
> Well, why not release Maven more often then? For those who need a freshly
> released plugin version urgently, there still could be an override
> mechanism.
>
> Eclipse.org makes coordinated releases of many sub-projects. The
> sub-projects do have an independent lifecycle, but there are coordinated
> schedules when bundles are published. So each user knows: Every June there's
> a new major Eclipse release, and between these releases there's a public
> visible schedule when new Milestone releases are published.

I think the only reason Eclipse can get away with this approach is
because IBM are funding a large proportion of the development efforts
with Eclipse.

Maven doesn't have that kind of cash backing to see this happen.

I agree with the points you are raising. I think the cop out answer
will be that Maven is open source and that if these features are
wanted enough then someone needs to scratch the itch and come up with
a solution.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Jason van Zyl <ja...@maven.org>]

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 some simple tools and better documentation  
here as there are many people who do have some simple strategies.

The most common one I know of is one person building everything and  
then flipping the local repository that was populated and turn that  
into the remote repository that the other developers use. You have to  
account for the metadata and we have some tools for this but it's not  
very easy to do. Some nice tools and IDE integration would make this  
very easy to do. It should be seamless.

> And I do agree that the separation of the Maven
> core and the plugins has its benefits, and the default distribution  
> should
> be without plugins.
>
> But it should be easy for those who want to work independently of  
> central to
> do it. Currently it is a pain.

Yes, it is and as a result we have people rsyncing the entire  
repository even though they need only 5% of the contents.

Jason.

>
>
> Jason van Zyl-2 wrote:
>>
>>> Many even don't want to proxy repo1 but instead manage their own
>>> repository. This is especially true for build artifacts (but it is
>>> also
>>> desirable for Maven plugins which currently would be a pain).
>>>
>>> 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 lifecycle of
>> plugins from the core because any plugins we house here may, in fact,
>> be release two or three times between major releases of Maven and
>> binding these versions in the core would be a bad idea.
>>
>
> Well, why not release Maven more often then? For those who need a  
> freshly
> released plugin version urgently, there still could be an override
> mechanism.
>
> Eclipse.org makes coordinated releases of many sub-projects. The
> sub-projects do have an independent lifecycle, but there are  
> coordinated
> schedules when bundles are published. So each user knows: Every  
> June there's
> a new major Eclipse release, and between these releases there's a  
> public
> visible schedule when new Milestone releases are published.
>
> From a user's point of perspective, this is easy to understand, as  
> you don't
> *have to* track the versions of all sub-projects like the Platform,  
> EMF,
> BIRT, ... You still *can* if you want. Users who want to stick to  
> stable
> versions simply wait until the next major release (published once a  
> year in
> the case of Eclipse).
>
>
>
>>> Currently, when downloading the
>>> Maven distribution, it is in a way uncomplete as even the core
>>> plugins are
>>> missing.
>>
>> That is intentional and won't change as the default distribution, but
>> we certainly could provide another if necessary or better yet provide
>> decent tooling so that it's very simple to setup Maven + a given
>> manifest of tools you want for a development team.
>>
>
> +1. Both can be good options.
>
>
>
>> Again, ultimately what you want is what everyone wants. An easy way
>> to have an initial setup, yet configurable, and provide rock solid
>> consistent builds. And that's what we're trying to achieve.
>>
>
> Good!
>
>
>
>> Making a static glob is not the solution.
>>
>
> Okay, I see that you run into other problems when delivering the  
> plugin
> versions within the Maven Super POM...
>
> At the end of the day, what I mainly wanted to throw into the  
> discussion is:
>
> - Maven should be usable almost out-of-the-box even for those users  
> that
> want to be completely independent from central. Currently this is  
> far too
> much pain. I agree to you, better tooling can be a good solution.  
> But to me,
> this tooling seems to be far away...(?)
>
> - Users (including but not limited to newbies) should be *able* to  
> see Maven
> + the main plugins as "The Maven build system", if they so want.  
> You should
> not force *every* user to keep an eye on the versions of the core,  
> all the
> plugins and so on. One solution could be to make coordinated  
> releases with a
> publicly visible and reliable schedule like they do on eclipse.org.
>
>
>
>>> - Provide a downloadable distribution that is completely
>>> independent of
>>> repo1, i.e. a distribution that contains 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 think it would indeed be of great value to many users, as long as  
> tools
> that make it really easy to package it together on your 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.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[ArneD <pu...@degenring.de>]

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 benefits, and the default distribution should
be without plugins.

But it should be easy for those who want to work independently of central to
do it. Currently it is a pain.


Jason van Zyl-2 wrote:
> 
>> Many even don't want to proxy repo1 but instead manage their own
>> repository. This is especially true for build artifacts (but it is  
>> also
>> desirable for Maven plugins which currently would be a pain).
>>
>> 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 lifecycle of  
> plugins from the core because any plugins we house here may, in fact,  
> be release two or three times between major releases of Maven and  
> binding these versions in the core would be a bad idea.
> 

Well, why not release Maven more often then? For those who need a freshly
released plugin version urgently, there still could be an override
mechanism.

Eclipse.org makes coordinated releases of many sub-projects. The
sub-projects do have an independent lifecycle, but there are coordinated
schedules when bundles are published. So each user knows: Every June there's
a new major Eclipse release, and between these releases there's a public
visible schedule when new Milestone releases are published.

>From a user's point of perspective, this is easy to understand, as you don't
*have to* track the versions of all sub-projects like the Platform, EMF,
BIRT, ... You still *can* if you want. Users who want to stick to stable
versions simply wait until the next major release (published once a year in
the case of Eclipse).



>> Currently, when downloading the
>> Maven distribution, it is in a way uncomplete as even the core  
>> plugins are
>> missing.
> 
> That is intentional and won't change as the default distribution, but  
> we certainly could provide another if necessary or better yet provide  
> decent tooling so that it's very simple to setup Maven + a given  
> manifest of tools you want for a development team.
> 

+1. Both can be good options.



> Again, ultimately what you want is what everyone wants. An easy way  
> to have an initial setup, yet configurable, and provide rock solid  
> consistent builds. And that's what we're trying to achieve.
> 

Good!



> Making a static glob is not the solution.
> 

Okay, I see that you run into other problems when delivering the plugin
versions within the Maven Super POM... 

At the end of the day, what I mainly wanted to throw into the discussion is:

- Maven should be usable almost out-of-the-box even for those users that
want to be completely independent from central. Currently this is far too
much pain. I agree to you, better tooling can be a good solution. But to me,
this tooling seems to be far away...(?)

- Users (including but not limited to newbies) should be *able* to see Maven
+ the main plugins as "The Maven build system", if they so want. You should
not force *every* user to keep an eye on the versions of the core, all the
plugins and so on. One solution could be to make coordinated releases with a
publicly visible and reliable schedule like they do on eclipse.org.



>> - Provide a downloadable distribution that is completely  
>> independent of
>> repo1, i.e. a distribution that contains 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 think it would indeed be of great value to many users, as long as tools
that make it really easy to package it together on your 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.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Jason van Zyl <ja...@maven.org>]

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 shield all their  
developers from central but generally still have someone who  
maintains a connection to central. Whether they mirror its contents  
inside their firewall, create internal repositories by running builds  
and turning local repos into remote repos for their developers, or  
using a proxy. All three are prevalent use cases.

That corporate users want something consistent and reliable is for  
certain, but cutting off the network effect that Maven provides is  
generally not desirable and defeats one of Maven's greatest virtues  
in that new things are immediately available for use. That we have  
bugs with the snapshot mechanism and not fully worked out patterns  
for versioning of parent POM and plugins just comes with Maven not  
being fully mature but don't throw the baby out with the bath water.

> Many even don't want to proxy repo1 but instead manage their own
> repository. This is especially true for build artifacts (but it is  
> also
> desirable for Maven plugins which currently would be a pain).
>
> 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 lifecycle of  
plugins from the core because any plugins we house here may, in fact,  
be release two or three times between major releases of Maven and  
binding these versions in the core would be a bad idea.

> Currently, when downloading the
> Maven distribution, it is in a way uncomplete as even the core  
> plugins are
> missing.

That is intentional and won't change as the default distribution, but  
we certainly could provide another if necessary or better yet provide  
decent tooling so that it's very simple to setup Maven + a given  
manifest of tools you want for a development team.

> In contrast, if you download Ant, for example, you get all core ant
> tasks. Yes, it it possible to download other tasks from elsewhere,  
> but what
> you get out-of-the-box contains the most important things. The same  
> if you
> download the Eclipse SDK. It is not just the Eclipse runtime but  
> instead a
> bundle of the runtime and plugins. It is good to be able to use new  
> plugins
> by just declaring them (as long as you have a connection to repo1),  
> but the
> Maven core plugins should be usable out-of-the-box, without a  
> connection to
> repo1.

I don't believe this is what most users want. I believe they would be  
more interested in setting up a complete environment for their  
developers and bundling is not very help here. Someone has to manage  
how developers work behind a firewall and this person is generally  
the one who populates an internal repository. Some tooling here would  
be far more useful.

>
> 3. Many corporate users prefer to wait for stable releases instead  
> of using
> beta versions. When using a stable Maven release, say 2.0.6, you  
> should get
> latest stable (!) versions of Maven plugins. For example, you do  
> not want to
> use maven-assembly-plugin 2.2-beta1 just because it has been  
> uploaded to
> ibiblio. But: You want it out-of-the-box. The last thing that  
> newbies want
> is to be forced to manually find out the latest version numbers and  
> declare
> them.

This is why we are promoting the requirement of specifying versions  
in addition to making it easy to find out those versions. Many users  
want different versions and we can't accommodate every possibility  
but putting this power in the users hands you can do whatever you like.

We had the notion of a plugin registry which was used locally by a  
developer but not enforceable team wide. I think this is the feature  
people are looking for. Some manifest that can be enforced and used  
as a mixin so that we don't have to bake it into Maven yet something  
we can provide. But we're always going to get a cross-section of  
users who want one thing and not another which is why we generally  
decide something and make everyone do it as the overall benefit to  
the group is higher. If we baked in versions some would complain  
loudly "I have no control over the versions of plugins", or if we  
provided an override mechanism some would expect the manifest to win,  
or the POM to be dominant.

Again, ultimately what you want is what everyone wants. An easy way  
to have an initial setup, yet configurable, and provide rock solid  
consistent builds. And that's what we're trying to achieve. Making a  
static glob is not the solution.

>
>
> 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's not ever going to be baked in.

>
> - Provide a downloadable distribution that is completely  
> independent of
> repo1, i.e. a distribution that contains 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.

Jason.

> 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 archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Stephane Nicoll <st...@gmail.com>]

On 4/13/07, ArneD <pu...@degenring.de> 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 couldn't expect a corporate pom to be changed that often.

>
> - Provide a downloadable distribution that is completely independent of
> repo1, i.e. a distribution that contains all Maven core plugins (in form of
> a pre-filled local repository, for example) in the latest stable version

Not 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 archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[ArneD <pu...@degenring.de>]

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 artifacts (but it is also
desirable for Maven plugins which currently would be a pain).

2. Many users don't want to make a distinction between Maven itself and the
Maven core plugins (compile, jar, ...). Currently, when downloading the
Maven distribution, it is in a way uncomplete as even the core plugins are
missing. In contrast, if you download Ant, for example, you get all core ant
tasks. Yes, it it possible to download other tasks from elsewhere, but what
you get out-of-the-box contains the most important things. The same if you
download the Eclipse SDK. It is not just the Eclipse runtime but instead a
bundle of the runtime and plugins. It is good to be able to use new plugins
by just declaring them (as long as you have a connection to repo1), but the
Maven core plugins should be usable out-of-the-box, without a connection to
repo1. 

3. Many corporate users prefer to wait for stable releases instead of using
beta versions. When using a stable Maven release, say 2.0.6, you should get
latest stable (!) versions of Maven plugins. For example, you do not want to
use maven-assembly-plugin 2.2-beta1 just because it has been uploaded to
ibiblio. But: You want it out-of-the-box. The last thing that newbies want
is to be forced to manually find out the latest version numbers and declare
them.


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).

- Provide a downloadable distribution that is completely independent of
repo1, i.e. a distribution that contains all Maven core plugins (in form of
a pre-filled local repository, for example) in the latest stable version

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 archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Jerome Lacoste <je...@gmail.com>]

On 4/11/07, Brett Porter <br...@apache.org> 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 override it, but I'd like to see plugin 'packs'
> as a better solution to reduce the amount of configuration needed).
>
> Thirdly, we need to think carefully about the impact on existing
> builds. We're not just impacting the people that wrote the build - we
> impact the random people that grab a project and unwittingly try and
> build it with 2.1 not knowing the author never tested that, and get
> the bad experience.

Aren't existing builds buildable with 2.0.x ?

If the support for auto-resolution us removed and the build fails with
2.1, can't a message saying "you might want to try maven 2.0.x
instead".

Related to that, is there a mojo that identifies potential version
upgrades ? I.e. message saying "you are using version 2.1 of compile
plugin but versions 2.2 and 2.3 were released" (and even better with a
release date and link to changelog...).

Jerome

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Jason van Zyl <ja...@maven.org>]

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 build it should be  
specified in the POM. For tools like the IDE file generators and  
Archetype defaulting to the latest version isn't going to screw up  
anyone's build but it might screw up some infrastructure tooling. If  
this was so inconvenient for users then that's fine but even not  
specifying the version of a tool could cause problems and if we  
provide an easy way to find versions users can specify them. I still  
don't know if defaulting for tool plugins is good, but it's  
definitely not good for anything you actually need to make your build  
work.

> 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 like to see plugin 'packs'  
> as a better solution to reduce the amount of configuration needed).
>

The equivalent of what Brian did for dependencyManagement would work  
well for plugin configurations.

> Thirdly, we need to think carefully about the impact on existing  
> builds. We're not just impacting the people that wrote the build -  
> we impact the random people that grab a project and unwittingly try  
> and build it with 2.1 not knowing the author never tested that, and  
> get the bad experience.

The model of the POM will be different where the schema and validator  
would change to have a version be mandatory. Along with 2.1 users are  
going to get a new model version so we can figure out what's best to  
do given a mismatch: point people to the new tool to detect  
configuration problems with versions or something else. People will  
have to consciously move to the new model.

>
> I'm still in favour of a compatibility mode that can be driven by  
> the prerequisites or the modelVersion. I say let people use the  
> dependency plugin now to start fixing their builds, but for 2.1 let  
> them make the conscious decision to move up to this.
>
> - Brett
>
> On 12/04/2007, at 2:54 AM, 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 resolve RELEASE or LATEST meta- 
>> versions
>> for plugins any more. I'd actually argue that this is bad practice  
>> for ANY
>> artifact that is to be resolved, including site skins, etc. since  
>> it kills
>> our ability to deprecate features.
>>
>> I'd like to completely remove this from the DefaultPluginManager  
>> in trunk,
>> so we can start moving away from this practice immediately.
>>
>> I guess this is an informal vote on the subject, but I wanted to get
>> everyone's opinions before I move on it, since it's a fairly  
>> important
>> change.
>>
>> Here's my +1.
>>
>> -john
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Trygve Laugstøl <tr...@apache.org>]

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 override it, but I'd like to see plugin 'packs' as a better solution 
> to reduce the amount of configuration needed).
> 
> Thirdly, we need to think carefully about the impact on existing builds. 
> We're not just impacting the people that wrote the build - we impact the 
> random people that grab a project and unwittingly try and build it with 
> 2.1 not knowing the author never tested that, and get the bad experience.
> 
> I'm still in favour of a compatibility mode that can be driven by the 
> prerequisites or the modelVersion. I say let people use the dependency 
> plugin now to start fixing their builds, but for 2.1 let them make the 
> conscious decision to move up to this.

I've talked about this before and I still mean that Maven should have a 
prerequisite flag for Maven version as you're saying.

--
Trygve

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Richard van der Hoff <ri...@mxtelecom.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 versions. 
Then, when a new version of maven is released, we have the same problem 
as we do now - people will upgrade and wonder why their build broke. 
Either that, or they will be in mortal fear of upgrading the maven core 
for fear of breaking something. Plugin version should definitely be tied 
to your project, not your maven version.

> Making the user list all plugins it's gonna be killer for newbies.

I agree with this part. There does need to be some way of tying down the 
versions of plugins used in the default lifecycle, other than forcing 
the pom writer to specify each one individually.

Perhaps could be done by having a centralised base-pom which people 
could inherit from? Or by having packagings specify default plugin 
versions - and then you would only need to specify the version of the 
plugin providing the packaging.

Regards,

Richard, who so far has only found one build which broke as a result of 
the assembly-plugin release...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Carlos Sanchez <ca...@apache.org>]

On 4/11/07, Barrie Treloar <ba...@gmail.com> wrote:
> On 4/12/07, Carlos Sanchez <ca...@apache.org> 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 to workaround a known issue) then
> I specify it in the the pom. Otherwise I want the latest.

and that was already identified as a problem with the current
implementation. I get the latest today and somebody else gets the
latest in two months, unless you run mvn -U

>
> 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.


that sounds good idea too, but we can only do it for the default
lifecycle, we can't lock down all possible plugins out there


>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[John Casey <ca...@gmail.com>]

The big problem with baking this stuff into a maven distro is the fact that
a new maven release can hose your build, and make you gunshy about ever
upgrading again. I suppose this is a counter-argument to my argument about
how putting the parent pom + lifecycle defs on central would make the Maven
distro a lifeless hull...

-j

On 4/12/07, Carlos Sanchez <ca...@apache.org> wrote:
>
> Maven already has the concept of super-pom with defaults, it makes
> sense to me to add the plugin versions as part of the defaults. You'd
> still have the problem of 2.1.0 may have different versions then 2.1.1
> but at least you don't need to ask for each plugin.
>
> Then I'd remove the -U option and make plugin version mandatory in the
> pom.
>
> I think these are easy steps that would solve most of the trouble and
> later we can revisit other features, like writing the "default"
> versions to the pom during release process.
>
> Advanced users already know how to lock down plugin versions so I
> wouldn't worry to much about that case.
>
>
> On 4/12/07, John Casey <ca...@gmail.com> wrote:
> > Let me see if I can address everything in the thread since the last time
> I
> > looked...here goes: :-)
> >
> > 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. In other
> > words, these particular versions may introduce a subtle problem that
> wasn't
> > present for other builds, because the other builds were done without
> > locked-down versions, and done on another dev's box (with a slightly
> > different set of plugin versions; remember the -U timing!). You could
> say
> > that this would be vetted out during the RC/voting process, but wouldn't
> it
> > be better to make it part of the daily bread-and-butter routine,
> assuming we
> > could make that routine a little easier to handle?
> >
> > 2. WRT specifying all versions for lifecycle plugins, I'd suggest the
> use of
> > either (a) a lifecycle/packaging version that would specify each
> plugin's
> > version, as was suggested on the users@ list; or, (b) a new piece of
> syntax
> > to specify a set of plugin versions that are commonly used together. (A)
> > wouldn't make much sense unless we externalized all of our packagings,
> > IMO...which makes Maven sort of a lifeless hull without at least an
> initial
> > internet connection. (B) gets you into the realm of maybe making these
> > plugin-sets additive (specify multiple of them in the same POM), and
> maybe
> > allowing them to provide configuration, etc...which is a whole new can
> of
> > worms, I guess.
> >
> > 3. I think it's quite dangerous to keep on the track of having the
> common
> > user use the current RELEASE meta-versions. We have to get out of this [
> > 1.0-2.0) mindset (where we're operating with basically the same
> feature-set
> > and no breaks in compatibility from release to release). RELEASE is
> > indiscriminate about compatibility rules, which means that any POM
> checked
> > in that relies on RELEASE meta-versions may break in the future. This is
> > compounded by the fact that new plugin versions are *never* detected
> unless
> > (a) the plugin hasn't been used before, and isn't in the local
> repository,
> > or (b) the user *chooses* to use -U...that means that for any two-member
> > development team, unless they're invoking -U in synchrony there is a
> real
> > potential for mismatched plugin versions.
> >
> > Wayne, your experiences wouldn't seem to be very encouraging for the
> idea of
> > writing more/better documentation. Would a cheat-sheet or a FAQ that's
> > well-organized help with these sorts of newbie problems?
> >
> > Dan/Carlos/Wayne/etc.: would it be reasonable to provide some nice
> plugins
> > (maybe with GUIs where we can) that will help users choose what they
> need?
> >
> > Peter: WRT the parent POM residing in central, see my comment about the
> > externalized packaging/lifecycle definitions...that would make Maven
> itself
> > fairly limited if something happens on the network. Right now, it is
> > possible (maybe a little tough, but possible) to use Maven
> offline...with an
> > externalized parent, you'd have to have an update policy or a mechanism
> for
> > specifying the root POM version, which would land you in a tricky spot
> WRT
> > multimodule builds.
> >
> > I'm sure I've missed out on someone's comments, but I think that pretty
> well
> > summarizes my thinking...
> >
> > -john
> >
> > On 4/12/07, Stephane Nicoll <st...@gmail.com> wrote:
> > >
> > > 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 <Pe...@fmr.com> 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:brianf@reply.infinity.nu]
> > > > 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: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>                              -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Carlos Sanchez <ca...@apache.org>]

Maven already has the concept of super-pom with defaults, it makes
sense to me to add the plugin versions as part of the defaults. You'd
still have the problem of 2.1.0 may have different versions then 2.1.1
but at least you don't need to ask for each plugin.

Then I'd remove the -U option and make plugin version mandatory in the pom.

I think these are easy steps that would solve most of the trouble and
later we can revisit other features, like writing the "default"
versions to the pom during release process.

Advanced users already know how to lock down plugin versions so I
wouldn't worry to much about that case.


On 4/12/07, John Casey <ca...@gmail.com> wrote:
> Let me see if I can address everything in the thread since the last time I
> looked...here goes: :-)
>
> 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. In other
> words, these particular versions may introduce a subtle problem that wasn't
> present for other builds, because the other builds were done without
> locked-down versions, and done on another dev's box (with a slightly
> different set of plugin versions; remember the -U timing!). You could say
> that this would be vetted out during the RC/voting process, but wouldn't it
> be better to make it part of the daily bread-and-butter routine, assuming we
> could make that routine a little easier to handle?
>
> 2. WRT specifying all versions for lifecycle plugins, I'd suggest the use of
> either (a) a lifecycle/packaging version that would specify each plugin's
> version, as was suggested on the users@ list; or, (b) a new piece of syntax
> to specify a set of plugin versions that are commonly used together. (A)
> wouldn't make much sense unless we externalized all of our packagings,
> IMO...which makes Maven sort of a lifeless hull without at least an initial
> internet connection. (B) gets you into the realm of maybe making these
> plugin-sets additive (specify multiple of them in the same POM), and maybe
> allowing them to provide configuration, etc...which is a whole new can of
> worms, I guess.
>
> 3. I think it's quite dangerous to keep on the track of having the common
> user use the current RELEASE meta-versions. We have to get out of this [
> 1.0-2.0) mindset (where we're operating with basically the same feature-set
> and no breaks in compatibility from release to release). RELEASE is
> indiscriminate about compatibility rules, which means that any POM checked
> in that relies on RELEASE meta-versions may break in the future. This is
> compounded by the fact that new plugin versions are *never* detected unless
> (a) the plugin hasn't been used before, and isn't in the local repository,
> or (b) the user *chooses* to use -U...that means that for any two-member
> development team, unless they're invoking -U in synchrony there is a real
> potential for mismatched plugin versions.
>
> Wayne, your experiences wouldn't seem to be very encouraging for the idea of
> writing more/better documentation. Would a cheat-sheet or a FAQ that's
> well-organized help with these sorts of newbie problems?
>
> Dan/Carlos/Wayne/etc.: would it be reasonable to provide some nice plugins
> (maybe with GUIs where we can) that will help users choose what they need?
>
> Peter: WRT the parent POM residing in central, see my comment about the
> externalized packaging/lifecycle definitions...that would make Maven itself
> fairly limited if something happens on the network. Right now, it is
> possible (maybe a little tough, but possible) to use Maven offline...with an
> externalized parent, you'd have to have an update policy or a mechanism for
> specifying the root POM version, which would land you in a tricky spot WRT
> multimodule builds.
>
> I'm sure I've missed out on someone's comments, but I think that pretty well
> summarizes my thinking...
>
> -john
>
> On 4/12/07, Stephane Nicoll <st...@gmail.com> wrote:
> >
> > 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 <Pe...@fmr.com> 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:brianf@reply.infinity.nu]
> > > 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: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Barrie Treloar <ba...@gmail.com>]

On 4/17/07, Kevin Menard <km...@servprise.com> 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.

That's not terribly helpful of the Selenium folks.

You should get more of their users to whinge.  Broken releases should
get fixed ASAP, or else dump Selenium and use something else.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Remove auto-resolution of plugin versions from Maven 2.1

[Kevin Menard <km...@servprise.com>]

Apologies for the delayed response.  I must've missed the message.

I'd have to check with Andrus Adamchik, since he was the guy that had to
keep fixing the POM.  I know for certain that we've been bitten numerous
times by the Geronimo folk though, both transitively and directly.  We
also got bit by the whole surefire/classloader issue, which the
suggestions in this thread would take care of.

For my own stuff, I've had to rely on SNAPSHOT for Selenium and Cargo,
because either the released versions were broken in some way or didn't
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.

-- 
Kevin 

> -----Original Message-----
> From: John Casey [mailto:casey.john.d@gmail.com] 
> 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 were they snapshots 
> from Maven or some other OSS project that you depend on or 
> use? If we start talking seriously about shorter dev cycles 
> and milestone releases with less of a barrier to release (for 
> alpha quality, for instance)...and start shunning snapshots 
> as an acceptable mechanism for distributing pre-release 
> code...would that have helped you all?
> 
> -john
> 
> On 4/12/07, Kevin Menard <km...@servprise.com> wrote:
> >
> > I agree.  I am suggesting that it's a little too easy to 
> use SNAPSHOTs 
> > and that all that wonderful time maven was supposed to save you in 
> > preparing releases is trumped by the time it takes to just append 
> > -SNAPSHOT to a version number.  Sure, it's people abusing 
> it, but it's 
> > easy to abuse and looks like it's officially condoned as proper 
> > behavior.  Things get even murkier when transitive dependencies are 
> > considered.  So, I'm not suggesting dumping SNAPSHOT wholesale, but 
> > making it more difficult to distribute an artifact via 
> SNAPSHOT (maybe 
> > require the end user to have to agree to use a new SNAPSHOT 
> each time 
> > one is available or something).
> >
> > Maybe we'll just have to agree to disagree.  I will say that this 
> > matter has bitten the Cayenne team a few times now, and we've come 
> > close to dumping maven altogether.  It got to the point 
> where we had 
> > to start pinning SNAPSHOTs by timestamp via a guess and 
> check method.  
> > Perhaps the plugin Nigel suggested would help matters, though.
> >
> > --
> > Kevin
> >
> > > -----Original Message-----
> > > From: Brian E. Fox [mailto:brianf@reply.infinity.nu]
> > > Sent: Thursday, April 12, 2007 3:10 PM
> > > To: Maven Developers List
> > > Subject: RE: Remove auto-resolution of plugin versions from Maven 
> > > 2.1
> > >
> > >  Snapshots are a very good thing for internal 
> development. It would 
> > > be impossible to manage my builds without them. I think 
> that people 
> > > using snapshots of plugins are a symptom of another 
> problem -- long 
> > > release cycles. Just because people do bad things with snapshots 
> > > doesn't mean snapshots should go away.
> > >
> > > It already takes a little effort to get at them, the 
> snapshot repo 
> > > isn't part of the super-pom, so if you go out of your way to get 
> > > them, you should understand the consequences. It's like 
> me picking 
> > > up an unstable version of some jar and then complaining that it 
> > > broke later and asking the creators to stop releasing unstable 
> > > versions at all(that are clearly marked as such). People 
> would then 
> > > just go get the code anyway.
> > >
> > > -----Original Message-----
> > > From: Kevin Menard [mailto:kmenard@servprise.com]
> > > 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 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.
> > >
> > > If the plan is to take actions to help prevent users from having 
> > > things break on them, this may be easier than the path 
> you outlined.
> > >
> > > --
> > > Kevin
> > >
> > > >
> > >
> > > 
> --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For 
> > > additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For 
> > additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[John Casey <ca...@gmail.com>]

I think it's wise to limit the use of snapshots, even to the point where we
say that it's not smart to publish your snapshots to a "public" location at
all. This gets a little dicey with OSS projects, since the team is so widely
distributed, but just saying that the snapshot repository is not supported
might help out.

What I'm really getting at is that projects shouldn't depend on snapshots
outside of their own development team (or that project, I guess is another
way of saying it). The habit of publishing snapshots to a public location
and telling everyone about them leads us away from milestone releases, which
are the first thing that anyone in the project's user community should ever
see.

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 or use? If we start talking seriously about
shorter dev cycles and milestone releases with less of a barrier to release
(for alpha quality, for instance)...and start shunning snapshots as an
acceptable mechanism for distributing pre-release code...would that have
helped you all?

-john

On 4/12/07, Kevin Menard <km...@servprise.com> wrote:
>
> I agree.  I am suggesting that it's a little too easy to use SNAPSHOTs
> and that all that wonderful time maven was supposed to save you in
> preparing releases is trumped by the time it takes to just append
> -SNAPSHOT to a version number.  Sure, it's people abusing it, but it's
> easy to abuse and looks like it's officially condoned as proper
> behavior.  Things get even murkier when transitive dependencies are
> considered.  So, I'm not suggesting dumping SNAPSHOT wholesale, but
> making it more difficult to distribute an artifact via SNAPSHOT (maybe
> require the end user to have to agree to use a new SNAPSHOT each time
> one is available or something).
>
> Maybe we'll just have to agree to disagree.  I will say that this matter
> has bitten the Cayenne team a few times now, and we've come close to
> dumping maven altogether.  It got to the point where we had to start
> pinning SNAPSHOTs by timestamp via a guess and check method.  Perhaps
> the plugin Nigel suggested would help matters, though.
>
> --
> Kevin
>
> > -----Original Message-----
> > From: Brian E. Fox [mailto:brianf@reply.infinity.nu]
> > Sent: Thursday, April 12, 2007 3:10 PM
> > To: Maven Developers List
> > Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1
> >
> >  Snapshots are a very good thing for internal development. It
> > would be impossible to manage my builds without them. I think
> > that people using snapshots of plugins are a symptom of
> > another problem -- long release cycles. Just because people
> > do bad things with snapshots doesn't mean snapshots should go away.
> >
> > It already takes a little effort to get at them, the snapshot
> > repo isn't part of the super-pom, so if you go out of your
> > way to get them, you should understand the consequences. It's
> > like me picking up an unstable version of some jar and then
> > complaining that it broke later and asking the creators to
> > stop releasing unstable versions at all(that are clearly
> > marked as such). People would then just go get the code anyway.
> >
> > -----Original Message-----
> > From: Kevin Menard [mailto:kmenard@servprise.com]
> > 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 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.
> >
> > If the plan is to take actions to help prevent users from
> > having things break on them, this may be easier than the path
> > you outlined.
> >
> > --
> > Kevin
> >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> > additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Barrie Treloar <ba...@gmail.com>]

On 4/13/07, Brian E. Fox <br...@reply.infinity.nu> 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 the whole thing and put
> it in my svn. If not, then the svnrev in the release points me back to
> where I got it in case I need it later.
> 4. Deploy it to my repos.
> 5. Use this now "internally released" version in my builds.
>
> It's a little extra work, especially when you get stuff that has further
> snapshot dependencies etc, but it is most definitely stable and
> reproducible. (even if our repo disappears).

This is similar to what I wrote up here:
http://docs.codehaus.org/display/MAVENUSER/Patching+Maven+Plugins

I'm not pushing things back into a local versioning system, but
relying on applying patches which have been put into JIRA.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Remove auto-resolution of plugin versions from Maven 2.1

[Kevin Menard <km...@servprise.com>]

I agree.  I am suggesting that it's a little too easy to use SNAPSHOTs
and that all that wonderful time maven was supposed to save you in
preparing releases is trumped by the time it takes to just append
-SNAPSHOT to a version number.  Sure, it's people abusing it, but it's
easy to abuse and looks like it's officially condoned as proper
behavior.  Things get even murkier when transitive dependencies are
considered.  So, I'm not suggesting dumping SNAPSHOT wholesale, but
making it more difficult to distribute an artifact via SNAPSHOT (maybe
require the end user to have to agree to use a new SNAPSHOT each time
one is available or something).

Maybe we'll just have to agree to disagree.  I will say that this matter
has bitten the Cayenne team a few times now, and we've come close to
dumping maven altogether.  It got to the point where we had to start
pinning SNAPSHOTs by timestamp via a guess and check method.  Perhaps
the plugin Nigel suggested would help matters, though.

-- 
Kevin

> -----Original Message-----
> From: Brian E. Fox [mailto:brianf@reply.infinity.nu] 
> Sent: Thursday, April 12, 2007 3:10 PM
> To: Maven Developers List
> Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1
> 
>  Snapshots are a very good thing for internal development. It 
> would be impossible to manage my builds without them. I think 
> that people using snapshots of plugins are a symptom of 
> another problem -- long release cycles. Just because people 
> do bad things with snapshots doesn't mean snapshots should go away. 
> 
> It already takes a little effort to get at them, the snapshot 
> repo isn't part of the super-pom, so if you go out of your 
> way to get them, you should understand the consequences. It's 
> like me picking up an unstable version of some jar and then 
> complaining that it broke later and asking the creators to 
> stop releasing unstable versions at all(that are clearly 
> marked as such). People would then just go get the code anyway.
> 
> -----Original Message-----
> From: Kevin Menard [mailto:kmenard@servprise.com]
> 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 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.
> 
> If the plan is to take actions to help prevent users from 
> having things break on them, this may be easier than the path 
> you outlined.
> 
> --
> Kevin
> 
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For 
> additional commands, e-mail: dev-help@maven.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Remove auto-resolution of plugin versions from Maven 2.1

["Brian E. Fox" <br...@reply.infinity.nu>]

 Snapshots are a very good thing for internal development. It would be
impossible to manage my builds without them. I think that people using
snapshots of plugins are a symptom of another problem -- long release
cycles. Just because people do bad things with snapshots doesn't mean
snapshots should go away. 

It already takes a little effort to get at them, the snapshot repo isn't
part of the super-pom, so if you go out of your way to get them, you
should understand the consequences. It's like me picking up an unstable
version of some jar and then complaining that it broke later and asking
the creators to stop releasing unstable versions at all(that are clearly
marked as such). People would then just go get the code anyway.

-----Original Message-----
From: Kevin Menard [mailto:kmenard@servprise.com] 
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 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.

If the plan is to take actions to help prevent users from having things
break on them, this may be easier than the path you outlined.

--
Kevin

>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Remove auto-resolution of plugin versions from Maven 2.1

[Kevin Menard <km...@servprise.com>]

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.

If the plan is to take actions to help prevent users from having things
break on them, this may be easier than the path you outlined.

-- 
Kevin

> -----Original Message-----
> From: Brian E. Fox [mailto:brianf@reply.infinity.nu] 
> Sent: Thursday, April 12, 2007 12:59 PM
> To: Maven Developers List
> Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1
> 
> Snapshots are not intended to be depended on outside the 
> context of the team working on it. Nothing released can ever 
> had snapshot dependencies (on plugins or dependencies). I 
> think what you are seeing is a symptom of longer release 
> cycles. People need something fixed, they take a snapshot and 
> move on. Unfortunately this is dangerous as you noted. We are 
> working on getting tighter release cycles and I think it's 
> starting to show recently.
> 
> 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 the svnrev in the release points me back to where I got 
> it in case I need it later.
> 4. Deploy it to my repos.
> 5. Use this now "internally released" version in my builds.
> 
> It's a little extra work, especially when you get stuff that 
> has further snapshot dependencies etc, but it is most 
> definitely stable and reproducible. (even if our repo disappears). 
> 
> -----Original Message-----
> From: Kevin Menard [mailto:kmenard@servprise.com]
> 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 dependencies sit in a SNAPSHOT 
> limbo, presumably because it's simpler than cutting a 
> release.  And then SNAPSHOT to SNAPSHOT may break builds.  In 
> this case, the user has specified precisely the version he 
> needs for his build (perhaps only SNAPSHOT has a particular 
> bug fix), but he's still just as vulnerable to having the rug 
> pulled out beneath him.
> 
> --
> Kevin
> 
> > -----Original Message-----
> > From: Brian E. Fox [mailto:brianf@reply.infinity.nu]
> > 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 dangerous to depend on the latest version of some jar from the 
> > repo, and likewise plugins. We don't default to grabbing the LATEST 
> > dependency, the same should be true for plugins.
> > 
> > -----Original Message-----
> > From: John Casey [mailto:casey.john.d@gmail.com]
> > 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 build script (or POM, or whatever 
> > binding you have to a build infrastructure) as a piece of 
> the project 
> > code. The build - definition, shall we say? - is responsible for 
> > modifying your source code into a binary that works the way 
> you would 
> > expect, and there are many options for the different steps 
> involved in
> 
> > this process. This complexity means that there is a risk that the 
> > build process could introduce unexpected problems that may 
> range from 
> > a file being out of place in the resulting binary, to a compiler 
> > option turned off that should be on, to using the wrong compiler.
> > 
> > In other words, your build process is subject to bugs just 
> like your 
> > project source code is, and needs to be tested alongside everything 
> > else. If you wait until release time to exercise a 
> particular piece of
> 
> > this code, that's not so different from having a piece of code with 
> > absolutely no tests make it into your final binary. This is the 
> > biggest reason why I feel that locking down the POM at 
> release time is
> 
> > dangerous.
> > 
> > -john
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For 
> > additional commands, e-mail: dev-help@maven.apache.org
> > 
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For 
> additional commands, e-mail: dev-help@maven.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For 
> additional commands, e-mail: dev-help@maven.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Brett Porter <br...@apache.org>]

This is what the release poms feature was meant to do - take a  
snapshot of what was actually resolved and use that for the release  
(and in the future).

The difficulty with it came in that what gets deployed is not what  
you want then (as it was also resolving the dependencies, etc). But  
that can be overcome.

I think this topic also starts to touch ever so slightly on the  
shelved discussion I started way back when about separating parts of  
the pom that serve different purposes (the declaration vs the  
instantiation, if you will).

Cheers,
Brett

On 12/04/2007, at 9:05 PM, Brian E. Fox wrote:

> I wrote this up here: http://jira.codehaus.org/browse/MNG-2945
>
> -----Original Message-----
> From: Nigel Magnay [mailto:nigel.magnay@gmail.com]
> 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 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 the svnrev in
>> the release points me back to where I got it in case I need it later.
>> 4. Deploy it to my repos.
>> 5. Use this now "internally released" version in my builds.
>>
>
> I've done this, and also with smaller external snapshots I've  
> downloaded
> them and just adjusted the metadata (and filename) before deploying to
> my local repos.
>
> What would be really, really, really useful would be a plugin that you
> could call that would download a snapshot of a project and its
> (transient,
> snapshot) dependencies, re-label it as a fixed internal version.  
> There's
> occasions where you just can't wait for an external project to release
> (and of course this problem is recursive!), and rebuilding everything
> yourself is a bit drag on the person doing a release.
>
> something like
> mvn artifact:freeze-snapshot org.apache.myfaces myfaces-all
> 1.1.6-SNAPSHOT 1.1.6-mycorp
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Remove auto-resolution of plugin versions from Maven 2.1

["Brian E. Fox" <br...@reply.infinity.nu>]

I wrote this up here: http://jira.codehaus.org/browse/MNG-2945 

-----Original Message-----
From: Nigel Magnay [mailto:nigel.magnay@gmail.com] 
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 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 the svnrev in 
> the release points me back to where I got it in case I need it later.
> 4. Deploy it to my repos.
> 5. Use this now "internally released" version in my builds.
>

I've done this, and also with smaller external snapshots I've downloaded
them and just adjusted the metadata (and filename) before deploying to
my local repos.

What would be really, really, really useful would be a plugin that you
could call that would download a snapshot of a project and its
(transient,
snapshot) dependencies, re-label it as a fixed internal version. There's
occasions where you just can't wait for an external project to release
(and of course this problem is recursive!), and rebuilding everything
yourself is a bit drag on the person doing a release.

something like
mvn artifact:freeze-snapshot org.apache.myfaces myfaces-all
1.1.6-SNAPSHOT 1.1.6-mycorp

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Remove auto-resolution of plugin versions from Maven 2.1

["Brian E. Fox" <br...@reply.infinity.nu>]

Yes I also agree this would be handy at times. 

-----Original Message-----
From: Wayne Fay [mailto:waynefay@gmail.com] 
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 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 <ni...@gmail.com> 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 the whole thing and put it in my svn. If not, then the svnrev 
> > in the release points me back to where I got it in case I need it 
> > later.
> > 4. Deploy it to my repos.
> > 5. Use this now "internally released" version in my builds.
> >
>
> I've done this, and also with smaller external snapshots I've 
> downloaded them and just adjusted the metadata (and filename) before 
> deploying to my local repos.
>
> What would be really, really, really useful would be a plugin that you

> could call that would download a snapshot of a project and its 
> (transient,
> snapshot) dependencies, re-label it as a fixed internal version. 
> There's occasions where you just can't wait for an external project to

> release (and of course this problem is recursive!), and rebuilding 
> everything yourself is a bit drag on the person doing a release.
>
> something like
> mvn artifact:freeze-snapshot org.apache.myfaces myfaces-all 
> 1.1.6-SNAPSHOT 1.1.6-mycorp
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional
commands, e-mail: dev-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Wayne Fay <wa...@gmail.com>]

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 <ni...@gmail.com> 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 the whole thing and put
> > it in my svn. If not, then the svnrev in the release points me back to
> > where I got it in case I need it later.
> > 4. Deploy it to my repos.
> > 5. Use this now "internally released" version in my builds.
> >
>
> I've done this, and also with smaller external snapshots I've downloaded
> them and just adjusted the metadata (and filename) before deploying to my
> local repos.
>
> What would be really, really, really useful would be a plugin that you could
> call that would download a snapshot of a project and its (transient,
> snapshot) dependencies, re-label it as a fixed internal version. There's
> occasions where you just can't wait for an external project to release (and
> of course this problem is recursive!), and rebuilding everything yourself is
> a bit drag on the person doing a release.
>
> something like
> mvn artifact:freeze-snapshot org.apache.myfaces myfaces-all 1.1.6-SNAPSHOT
> 1.1.6-mycorp
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Nigel Magnay <ni...@gmail.com>]

>
> 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 the svnrev in the release points me back to
> where I got it in case I need it later.
> 4. Deploy it to my repos.
> 5. Use this now "internally released" version in my builds.
>

I've done this, and also with smaller external snapshots I've downloaded
them and just adjusted the metadata (and filename) before deploying to my
local repos.

What would be really, really, really useful would be a plugin that you could
call that would download a snapshot of a project and its (transient,
snapshot) dependencies, re-label it as a fixed internal version. There's
occasions where you just can't wait for an external project to release (and
of course this problem is recursive!), and rebuilding everything yourself is
a bit drag on the person doing a release.

something like
mvn artifact:freeze-snapshot org.apache.myfaces myfaces-all 1.1.6-SNAPSHOT
1.1.6-mycorp

RE: Remove auto-resolution of plugin versions from Maven 2.1

["Brian E. Fox" <br...@reply.infinity.nu>]

Snapshots are not intended to be depended on outside the context of the
team working on it. Nothing released can ever had snapshot dependencies
(on plugins or dependencies). I think what you are seeing is a symptom
of longer release cycles. People need something fixed, they take a
snapshot and move on. Unfortunately this is dangerous as you noted. We
are working on getting tighter release cycles and I think it's starting
to show recently.

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 the svnrev in the release points me back to
where I got it in case I need it later.
4. Deploy it to my repos.
5. Use this now "internally released" version in my builds.

It's a little extra work, especially when you get stuff that has further
snapshot dependencies etc, but it is most definitely stable and
reproducible. (even if our repo disappears). 

-----Original Message-----
From: Kevin Menard [mailto:kmenard@servprise.com] 
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 dependencies sit in a SNAPSHOT limbo,
presumably because it's simpler than cutting a release.  And then
SNAPSHOT to SNAPSHOT may break builds.  In this case, the user has
specified precisely the version he needs for his build (perhaps only
SNAPSHOT has a particular bug fix), but he's still just as vulnerable to
having the rug pulled out beneath him.

--
Kevin

> -----Original Message-----
> From: Brian E. Fox [mailto:brianf@reply.infinity.nu]
> 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 dangerous to depend on the latest version of some jar from the 
> repo, and likewise plugins. We don't default to grabbing the LATEST 
> dependency, the same should be true for plugins.
> 
> -----Original Message-----
> From: John Casey [mailto:casey.john.d@gmail.com]
> 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 build script (or POM, or whatever 
> binding you have to a build infrastructure) as a piece of the project 
> code. The build - definition, shall we say? - is responsible for 
> modifying your source code into a binary that works the way you would 
> expect, and there are many options for the different steps involved in

> this process. This complexity means that there is a risk that the 
> build process could introduce unexpected problems that may range from 
> a file being out of place in the resulting binary, to a compiler 
> option turned off that should be on, to using the wrong compiler.
> 
> In other words, your build process is subject to bugs just like your 
> project source code is, and needs to be tested alongside everything 
> else. If you wait until release time to exercise a particular piece of

> this code, that's not so different from having a piece of code with 
> absolutely no tests make it into your final binary. This is the 
> biggest reason why I feel that locking down the POM at release time is

> dangerous.
> 
> -john
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For 
> additional commands, e-mail: dev-help@maven.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional
commands, e-mail: dev-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Remove auto-resolution of plugin versions from Maven 2.1

[Kevin Menard <km...@servprise.com>]

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 limbo,
presumably because it's simpler than cutting a release.  And then
SNAPSHOT to SNAPSHOT may break builds.  In this case, the user has
specified precisely the version he needs for his build (perhaps only
SNAPSHOT has a particular bug fix), but he's still just as vulnerable to
having the rug pulled out beneath him.

-- 
Kevin

> -----Original Message-----
> From: Brian E. Fox [mailto:brianf@reply.infinity.nu] 
> 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 dangerous to depend on the latest 
> version of some jar from the repo, and likewise plugins. We 
> don't default to grabbing the LATEST dependency, the same 
> should be true for plugins. 
> 
> -----Original Message-----
> From: John Casey [mailto:casey.john.d@gmail.com]
> 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 build script (or POM, or 
> whatever binding you have to a build infrastructure) as a 
> piece of the project code. The build - definition, shall we 
> say? - is responsible for modifying your source code into a 
> binary that works the way you would expect, and there are 
> many options for the different steps involved in this 
> process. This complexity means that there is a risk that the 
> build process could introduce unexpected problems that may 
> range from a file being out of place in the resulting binary, 
> to a compiler option turned off that should be on, to using 
> the wrong compiler.
> 
> In other words, your build process is subject to bugs just 
> like your project source code is, and needs to be tested 
> alongside everything else. If you wait until release time to 
> exercise a particular piece of this code, that's not so 
> different from having a piece of code with absolutely no 
> tests make it into your final binary. This is the biggest 
> reason why I feel that locking down the POM at release time 
> is dangerous.
> 
> -john
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For 
> additional commands, e-mail: dev-help@maven.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Remove auto-resolution of plugin versions from Maven 2.1

["Brian E. Fox" <br...@reply.infinity.nu>]

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 dangerous to depend on the latest version of some jar from the
repo, and likewise plugins. We don't default to grabbing the LATEST
dependency, the same should be true for plugins. 

-----Original Message-----
From: John Casey [mailto:casey.john.d@gmail.com] 
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 build script (or POM, or whatever
binding you have to a build infrastructure) as a piece of the project
code. The build - definition, shall we say? - is responsible for
modifying your source code into a binary that works the way you would
expect, and there are many options for the different steps involved in
this process. This complexity means that there is a risk that the build
process could introduce unexpected problems that may range from a file
being out of place in the resulting binary, to a compiler option turned
off that should be on, to using the wrong compiler.

In other words, your build process is subject to bugs just like your
project source code is, and needs to be tested alongside everything
else. If you wait until release time to exercise a particular piece of
this code, that's not so different from having a piece of code with
absolutely no tests make it into your final binary. This is the biggest
reason why I feel that locking down the POM at release time is
dangerous.

-john


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[John Casey <ca...@gmail.com>]

One thing I wanted to add:

To me, it's critical to view your build script (or POM, or whatever binding
you have to a build infrastructure) as a piece of the project code. The
build - definition, shall we say? - is responsible for modifying your source
code into a binary that works the way you would expect, and there are many
options for the different steps involved in this process. This complexity
means that there is a risk that the build process could introduce unexpected
problems that may range from a file being out of place in the resulting
binary, to a compiler option turned off that should be on, to using the
wrong compiler.

In other words, your build process is subject to bugs just like your project
source code is, and needs to be tested alongside everything else. If you
wait until release time to exercise a particular piece of this code, that's
not so different from having a piece of code with absolutely no tests make
it into your final binary. This is the biggest reason why I feel that
locking down the POM at release time is dangerous.

-john

On 4/12/07, John Casey <ca...@gmail.com> wrote:
>
> Let me see if I can address everything in the thread since the last time I
> looked...here goes: :-)
>
> 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. In other
> words, these particular versions may introduce a subtle problem that wasn't
> present for other builds, because the other builds were done without
> locked-down versions, and done on another dev's box (with a slightly
> different set of plugin versions; remember the -U timing!). You could say
> that this would be vetted out during the RC/voting process, but wouldn't it
> be better to make it part of the daily bread-and-butter routine, assuming we
> could make that routine a little easier to handle?
>
> 2. WRT specifying all versions for lifecycle plugins, I'd suggest the use
> of either (a) a lifecycle/packaging version that would specify each plugin's
> version, as was suggested on the users@ list; or, (b) a new piece of syntax
> to specify a set of plugin versions that are commonly used together. (A)
> wouldn't make much sense unless we externalized all of our packagings,
> IMO...which makes Maven sort of a lifeless hull without at least an initial
> internet connection. (B) gets you into the realm of maybe making these
> plugin-sets additive (specify multiple of them in the same POM), and maybe
> allowing them to provide configuration, etc...which is a whole new can of
> worms, I guess.
>
> 3. I think it's quite dangerous to keep on the track of having the common
> user use the current RELEASE meta-versions. We have to get out of this [
> 1.0-2.0) mindset (where we're operating with basically the same
> feature-set and no breaks in compatibility from release to release). RELEASE
> is indiscriminate about compatibility rules, which means that any POM
> checked in that relies on RELEASE meta-versions may break in the future.
> This is compounded by the fact that new plugin versions are *never* detected
> unless (a) the plugin hasn't been used before, and isn't in the local
> repository, or (b) the user *chooses* to use -U...that means that for any
> two-member development team, unless they're invoking -U in synchrony there
> is a real potential for mismatched plugin versions.
>
> Wayne, your experiences wouldn't seem to be very encouraging for the idea
> of writing more/better documentation. Would a cheat-sheet or a FAQ that's
> well-organized help with these sorts of newbie problems?
>
> Dan/Carlos/Wayne/etc.: would it be reasonable to provide some nice plugins
> (maybe with GUIs where we can) that will help users choose what they need?
>
> Peter: WRT the parent POM residing in central, see my comment about the
> externalized packaging/lifecycle definitions...that would make Maven itself
> fairly limited if something happens on the network. Right now, it is
> possible (maybe a little tough, but possible) to use Maven offline...with an
> externalized parent, you'd have to have an update policy or a mechanism for
> specifying the root POM version, which would land you in a tricky spot WRT
> multimodule builds.
>
> I'm sure I've missed out on someone's comments, but I think that pretty
> well summarizes my thinking...
>
> -john
>
> On 4/12/07, Stephane Nicoll <st...@gmail.com> wrote:
> >
> > 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 <Pe...@fmr.com> 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:brianf@reply.infinity.nu]
> > > 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: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Brett Porter <br...@apache.org>]

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 problem you describe still remains  
(if the stuff changes before you cut the release but after you last  
tested it, which is why staging is a good idea). But locking it down  
at release time is not the problem, it's the lack of locking it down  
earlier (if that makes any sense).

> 2. WRT specifying all versions for lifecycle plugins, I'd suggest  
> the use of
> either (a) a lifecycle/packaging version that would specify each  
> plugin's
> version, as was suggested on the users@ list; or, (b) a new piece  
> of syntax
> to specify a set of plugin versions that are commonly used together.

Agreed. Rough proposal to follow.

> 3. I think it's quite dangerous to keep on the track of having the  
> common
> user use the current RELEASE meta-versions.

I think we need to consider ways to make this more workable in the  
long run, especially since version ranges suffer the same problems.  
The important thing to me is that it is possible to make it  
deterministic, and that that is considered best practice and easily  
encouraged by Maven.

> Dan/Carlos/Wayne/etc.: would it be reasonable to provide some nice  
> plugins
> (maybe with GUIs where we can) that will help users choose what  
> they need?

I think this helps, but I don't think it should be required to be  
able to figure Maven out.

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Brett Porter <br...@apache.org>]

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 way to automatically do
> that but that won't happen for a few years. Ideally this would happen
> once every 3-6 mos to keep the FAQ current and useful.

+1, any volunteers? :)

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Jose Alberto Fernandez <jo...@cellectivity.com>]

Wendy Smoak-3 wrote:
> 
> On 4/21/07, Jose Alberto Fernandez <jo...@cellectivity.com> 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.nabble.com/Publishing-plugin-docs-t3621488.html
> 
>> And having a documentation that does
>> not indicate which feature of a plugin was added on which version is also
>> a
>> major fault.
> 
> But the plugin docs should already point out what version a feature
> appeared in.  If you find this isn't true, please point out examples
> so we can fix it.
> 
> 

A good example can be found at:
http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html
The whole 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-versions-from-Maven-2.1-tf3560617s177.html#a10137579
Sent from the Maven Developers mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Wendy Smoak <ws...@gmail.com>]

On 4/21/07, Jose Alberto Fernandez <jo...@cellectivity.com> 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.nabble.com/Publishing-plugin-docs-t3621488.html

> And having a documentation that does
> not indicate which feature of a plugin was added on which version is also a
> major fault.

But the plugin docs should already point out what version a feature
appeared in.  If you find this isn't true, please point out examples
so we can fix it.

-- 
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Jason van Zyl <ja...@maven.org>]

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 communicate or even know about each other.
>

I think the only time I've seen it happen is with plexus-utils when  
there are differing versions. There are no functional  
incompatibilities in the plugins but dependency incompatibilities.

> I personally think all these solutions are overly complicated. I think
> we just need to find a way to make it easy to specify the versions of
> plugins in your poms.

Right, we just need to make it easy to find the versions and then the  
POM rules. Any automagical mechanism will be the death of us.

Jason.

>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Remove auto-resolution of plugin versions from Maven 2.1

[David Roussel <na...@diroussel.xsmail.com>]

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 finding out what version of
> what to use. And it could allow for auto upgrading in a more consistent
> manner, if the user so chooses.
> 

Indeed,  I'd rather version bump the bundle than version bump each
individual plugin.

If we are going to reccomend that all 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-resolution-of-plugin-versions-from-Maven-2.1-tf3560617s177.html#a10164518
Sent from the Maven Developers mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Remove auto-resolution of plugin versions from Maven 2.1

[Jose Alberto Fernandez <jo...@cellectivity.com>]

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 use.
And it could allow for auto upgrading in a more consistent manner, if the
user so chooses.


Brian E. Fox wrote:
> 
>  
> Yes, but if you specify which version of each in your pom, then it will
> only change when you want it to. You change the producer (or consumer)
> and find they don't work, you put it back or update the other and test.
> The whole point of specifying the versions manually is so that some
> human makes a conscious decision to update and presumably does some
> testing before pushing out to the rest of the team.
> 
> "I see it more about having certifications and provide users with stuff
> that we all know work well together. 
> For example, if I try using the ant-run-plugin on 2.0.5 I need to use
> ant-1.6.5 even though ant-1.7.0 is out. And this means you are limited
> to the ant-ssh library version you can use, and the jsch version you can
> use and so on."
> 
> These aren't multiple plugins you refer to, this is a specific problem
> with a single plugin and its dependencies. While unfortunate, I don't
> think we're even discussing attempting to bundle plugins and all their
> related dependencies together.
> 

Well, I needed to use Antrun which means I needed atd-1.6.5 but why should I
need to specify every single jar that is part of ANT-1.6.5 separately? And
why I do not have the correct dependencies in the repository for those? I
should not need to deal with all that, I thought that was what the
repository metadata was for.

Otherwise, there is something really missing. How is maven suppose to deal
with things that have multiple jars that work together? Certainly this is a
basic thing.

In any case I digress here. Look at bundles as a friendly way to define a
<dependencyManagement> or <pluginManagement> group, that users can
incorporate (like multiple inheritance). So there is a way to centralize
some of this management and simplify everyone's life.

And of course, do not forget being able to specify an upgrade strategy that
takes into account the idea of <quality> of the bundle. 

Call it 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-from-Maven-2.1-tf3560617s177.html#a10142950
Sent from the Maven Developers mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Remove auto-resolution of plugin versions from Maven 2.1

["Brian E. Fox" <br...@reply.infinity.nu>]

 
"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
versions of the same library that cause some havoc when used together,
because they are incompatible. "

Yes, but if you specify which version of each in your pom, then it will
only change when you want it to. You change the producer (or consumer)
and find they don't work, you put it back or update the other and test.
The whole point of specifying the versions manually is so that some
human makes a conscious decision to update and presumably does some
testing before pushing out to the rest of the team.

"I see it more about having certifications and provide users with stuff
that we all know work well together. 
For example, if I try using the ant-run-plugin on 2.0.5 I need to use
ant-1.6.5 even though ant-1.7.0 is out. And this means you are limited
to the ant-ssh library version you can use, and the jsch version you can
use and so on."

These aren't multiple plugins you refer to, this is a specific problem
with a single plugin and its dependencies. While unfortunate, I don't
think we're even discussing attempting to bundle plugins and all their
related dependencies together.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Remove auto-resolution of plugin versions from Maven 2.1

[Jose Alberto Fernandez <jo...@cellectivity.com>]

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 other. 
> 
> 

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 versions of
the same library that cause some havoc when used together, because they are
incompatible. 

I see it more about having certifications and provide users with stuff that
we all know work well together. 
For example, if I try using the ant-run-plugin on 2.0.5 I need to use
ant-1.6.5 even though ant-1.7.0 is out. And this means you are limited to
the ant-ssh library version you can use, and the jsch version you can use
and so on.
It took me I do not how long until I could get all those version in a way
that I think 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 the Maven Developers mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Remove auto-resolution of plugin versions from Maven 2.1

[David Roussel <na...@diroussel.xsmail.com>]

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 other. 
> 

The war pluing depends on the jar plugin.  A bug in the jar plugin could
cause the war plugin to fail. 

The cobertura-maven-plugin v2.1 depends on cobertura v1.8.  But cobertura
v1.8 has a bug.  cobertura-maven-plugin v2.0 depends 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
Sent from the Maven Developers mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Remove auto-resolution of plugin versions from Maven 2.1

["Brian E. Fox" <br...@reply.infinity.nu>]

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 all these solutions are overly complicated. I think
we just need to find a way to make it easy to specify the versions of
plugins in your poms.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Jose Alberto Fernandez <jo...@cellectivity.com>]

Wayne Fay wrote:
> 
> On 4/21/07, Jose Alberto Fernandez <jo...@cellectivity.com> wrote:
>> So if I say <quality>BETA</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 kernel and
> Apache webserver come to mind), very few seem to have a good sense for
> this, and I'm not even positive I'd totally trust myself with that
> decision for code I'm working on at times. We already have enough
> trouble getting projects to provide us with very basic poms, much less
> providing full poms with these kinds of details. So right off the bat,
> this sounds like a losing proposition for 95% of the projects in the
> wild.
> 
> Also, what happens when I specify <quality>BETA</quality> and depend
> on artifact xyz which brings in xyz-1.0.2-BETA which has a dependency
> on artifact abc-2.0.1-ALPHA? Will you expect Maven to pick xyz-1.0.1
> (final) which depended on abc-2.0.0 (final) since it can't satisfy all
> transitive requirements with BETA quality code? This just doesn't seem
> manageable for anyone...
> 
> 

You bring very good points indeed, my first answer is that we should start
simple ;-)
So let me explain my evolving thoughts...

Notice I mentioned "bundles" and not "artefacts". To me a bundle is for
example all the plugins build by the maven core project itself. As part of
the release on maven 2.x.y you guys should release maven 2.x.y plugin
bundle, which should specify a quality level of lets say "RELEASED". 

Maven 2.x.y should by default require a maven-plugin-bundle with version
"[2.x.y,)" and quality "RELEASED" or maybe "BETA" (if you think users should
try being more adventurous).

Now you ask, what is a bundle? A bundle is a collection of plugins that have
passed some testing process and are found to work well together. And its
quality should indicate how stable the artefacts on the bundle are
considered to be. The idea of the bundle is that when maven decides to
upgrade you to a newer level it will do it not based on one artefact at the
time but based on a collection of artefacts that were certified to work well
together. The versions of artefacts specified in the bundle will be used,
unless the artefact dependency declaration specifies an specific version.

Other big projects (reputable) projects or corporate entities may define
their own bundles and define what they think is "ALPHA", "BETA", "RELEASED"
or whatever level names you decide to use. What happens if more than one
bundle mention the same artefact at a different version, I have no clue. But
you already deal with this issue in the case of transitive dependencies
causing a conflict. I guess the rules should be similar.

Now, you still can use an artefact that does not belong to a bundle, but in
such a case I would suggest that best practice should be for the user to
specify at least a version range so he/she is not taken by surprise. For
example allow only minor releases "[1.5, 1.6)". Maven should probably give a
warning if I try using an artefact without version which it is not part of
bundle.

Now, about transitive dependencies, if my release code depends on something
alpha, should I really call my code stable? This is where good practice
comes along. Shall I provide my own version (like people do for snapshots)? 
Maven will need to 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.

Hope this  makes some sense...

Jose Alberto
-- 
View this message in context: http://www.nabble.com/Remove-auto-resolution-of-plugin-versions-from-Maven-2.1-tf3560617s177.html#a10138426
Sent from the Maven Developers mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[David Roussel <na...@diroussel.xsmail.com>]

Wayne Fay wrote:
> 
> On 4/21/07, Jose Alberto Fernandez <jo...@cellectivity.com> wrote:
>> So if I say <quality>BETA</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 kernel and
> Apache webserver come to mind), very few seem to have a good sense for
> this, and I'm not even positive I'd totally trust myself with that
> decision for code I'm working on at times. We already have enough
> trouble getting projects to provide us with very basic poms, much less
> providing full poms with these kinds of details. So right off the bat,
> this sounds like a losing proposition for 95% of the projects in the
> wild.
> 
> Also, what happens when I specify <quality>BETA</quality> and depend
> on artifact xyz which brings in xyz-1.0.2-BETA which has a dependency
> on artifact abc-2.0.1-ALPHA? Will you expect Maven to pick xyz-1.0.1
> (final) which depended on abc-2.0.0 (final) since it can't satisfy all
> transitive requirements with BETA quality code? This just doesn't seem
> manageable for anyone...
> 
> Of course, its much easier to find problems than solutions, so I don't
> want to discourage you from continuing the discussion. I just don't
> think this is the solution.
> 
> Wayne
> 

Does this problem come from the fact that the labels alpha, beta and final
are too tightly linked to a given release?  Actually these are labels and
should be independent of the build.   When revision 234 of xyz-plugin is
released, we might label it alpha, but if no defects are found after a lot
of of testing the we could call that same build final.  It's still a build
of revision 234, but now it's final.

If we had this kind of separation between builds and labels then it would be
easier to solve the "all the transitive dependencies of maven final should
be final" problem.

A complete change in the handling of 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
leadership over a great number of small projects it's difficult.

David 


-- 
View this message in context: http://www.nabble.com/Remove-auto-resolution-of-plugin-versions-from-Maven-2.1-tf3560617s177.html#a10144515
Sent from the Maven Developers mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Jason van Zyl <ja...@maven.org>]

On 22 Apr 07, at 11:09 PM 22 Apr 07, Wayne Fay wrote:

> On 4/21/07, Jose Alberto Fernandez <jo...@cellectivity.com> wrote:
>> So if I say <quality>BETA</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 on. All this will do is lend itself toward people not making  
then high quality releases. In the case of the assembly plugin, and  
several other plugins, they just went far too long without and we're  
trying to sort it out as fast as possible. All releases should be  
good. The arbitrary demarcation of quality is sketchy at best, and  
ultimately we're moving toward people specify all versions so you  
will consciously have to move forward, on something like the assembly  
plugin, and decide yourself if a given beta is good enough. Trying to  
bake this into Maven where it avoids alphas and betas automatically  
is not something I want to see.

Jason.

>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Wayne Fay <wa...@gmail.com>]

On 4/21/07, Jose Alberto Fernandez <jo...@cellectivity.com> wrote:
> So if I say <quality>BETA</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 kernel and
Apache webserver come to mind), very few seem to have a good sense for
this, and I'm not even positive I'd totally trust myself with that
decision for code I'm working on at times. We already have enough
trouble getting projects to provide us with very basic poms, much less
providing full poms with these kinds of details. So right off the bat,
this sounds like a losing proposition for 95% of the projects in the
wild.

Also, what happens when I specify <quality>BETA</quality> and depend
on artifact xyz which brings in xyz-1.0.2-BETA which has a dependency
on artifact abc-2.0.1-ALPHA? Will you expect Maven to pick xyz-1.0.1
(final) which depended on abc-2.0.0 (final) since it can't satisfy all
transitive requirements with BETA quality code? This just doesn't seem
manageable for anyone...

Of course, its much easier to find problems than solutions, so I don't
want to discourage you from continuing the discussion. I just don't
think this is the solution.

Wayne

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Jose Alberto Fernandez <jo...@cellectivity.com>]

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
> and comments about javax.* files with a link to the "how to deal with
> sun jars" page).
> 

Well, having the documentation not reflecting the released plugins but
SNAPSHOTs is not helpful to any user. And having a documentation that does
not indicate which feature of a plugin was added on which version is also a
major fault.

Really, when I look at the plugins that mvn have downloaded automagically
for our builds and you see alpha and beta releases and so on. And then you
go and look at the official documentation on the maven site and it refers to
the features of an SNAPSHOT version that has never been released. Well, you
can hardly put the blame on the users for being lazy readers.

As per the topic at hand, it makes absolute sense to have some sort of
certification process where the maven project gives some guarantees that the
plugins in a certified bundle work correctly together and that they have
been released following high standards. This to me is a basic requirement of
best practice.

Maven should support a way to specify bundles of plugins that fulfill a
certain quality level as expected for a particular project. You could
provide a mechanism where users can specify in the POM the level of quality
of the plugins and maven will only download plugins from bundles of the
appropriate certification group.

So if I say <quality>BETA</quality> then no alpha bundle (a bundle
containing alpha software) will be selected.
Of course, one should be able to specify the specific bundle version one
wants to use. 

You can see that something like this would allow users to cater to their
needs, if you want to use bleading adge software you can, but if you want to
use only released versions, like in a corporate environment, then you can do
that 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 Developers mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Wayne Fay <wa...@gmail.com>]

John, you asked me two questions...

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
and comments about javax.* files with a link to the "how to deal with
sun jars" page).

And then we need to include a prominent link on the homepage "Run
Maven... Use Maven... Having problems?" Hopefully some of the users
would see the "Having problems?" link on the site and resolve their
problems without emailing, and if they do send an email, we can simply
say "rtfm (read the faq, moron)." ;-)

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 way to automatically do
that but that won't happen for a few years. Ideally this would happen
once every 3-6 mos to keep the FAQ current and useful.

Regarding the "nice plugins and GUI to help" -- this sounds great.
I've seen this GUI concept actually discussed by a couple users over
the last few months, and I've pointed a couple of them who were
looking to actually implement something like that themselves at the
embedder, but haven't seen anything produced yet from anyone.

Wayne

On 4/12/07, John Casey <ca...@gmail.com> wrote:
> Let me see if I can address everything in the thread since the last time I
> looked...here goes: :-)
>
> 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. In other
> words, these particular versions may introduce a subtle problem that wasn't
> present for other builds, because the other builds were done without
> locked-down versions, and done on another dev's box (with a slightly
> different set of plugin versions; remember the -U timing!). You could say
> that this would be vetted out during the RC/voting process, but wouldn't it
> be better to make it part of the daily bread-and-butter routine, assuming we
> could make that routine a little easier to handle?
>
> 2. WRT specifying all versions for lifecycle plugins, I'd suggest the use of
> either (a) a lifecycle/packaging version that would specify each plugin's
> version, as was suggested on the users@ list; or, (b) a new piece of syntax
> to specify a set of plugin versions that are commonly used together. (A)
> wouldn't make much sense unless we externalized all of our packagings,
> IMO...which makes Maven sort of a lifeless hull without at least an initial
> internet connection. (B) gets you into the realm of maybe making these
> plugin-sets additive (specify multiple of them in the same POM), and maybe
> allowing them to provide configuration, etc...which is a whole new can of
> worms, I guess.
>
> 3. I think it's quite dangerous to keep on the track of having the common
> user use the current RELEASE meta-versions. We have to get out of this [
> 1.0-2.0) mindset (where we're operating with basically the same feature-set
> and no breaks in compatibility from release to release). RELEASE is
> indiscriminate about compatibility rules, which means that any POM checked
> in that relies on RELEASE meta-versions may break in the future. This is
> compounded by the fact that new plugin versions are *never* detected unless
> (a) the plugin hasn't been used before, and isn't in the local repository,
> or (b) the user *chooses* to use -U...that means that for any two-member
> development team, unless they're invoking -U in synchrony there is a real
> potential for mismatched plugin versions.
>
> Wayne, your experiences wouldn't seem to be very encouraging for the idea of
> writing more/better documentation. Would a cheat-sheet or a FAQ that's
> well-organized help with these sorts of newbie problems?
>
> Dan/Carlos/Wayne/etc.: would it be reasonable to provide some nice plugins
> (maybe with GUIs where we can) that will help users choose what they need?
>
> Peter: WRT the parent POM residing in central, see my comment about the
> externalized packaging/lifecycle definitions...that would make Maven itself
> fairly limited if something happens on the network. Right now, it is
> possible (maybe a little tough, but possible) to use Maven offline...with an
> externalized parent, you'd have to have an update policy or a mechanism for
> specifying the root POM version, which would land you in a tricky spot WRT
> multimodule builds.
>
> I'm sure I've missed out on someone's comments, but I think that pretty well
> summarizes my thinking...
>
> -john
>
> On 4/12/07, Stephane Nicoll <st...@gmail.com> wrote:
> >
> > 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 <Pe...@fmr.com> 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:brianf@reply.infinity.nu]
> > > 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: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[John Casey <ca...@gmail.com>]

Let me see if I can address everything in the thread since the last time I
looked...here goes: :-)

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. In other
words, these particular versions may introduce a subtle problem that wasn't
present for other builds, because the other builds were done without
locked-down versions, and done on another dev's box (with a slightly
different set of plugin versions; remember the -U timing!). You could say
that this would be vetted out during the RC/voting process, but wouldn't it
be better to make it part of the daily bread-and-butter routine, assuming we
could make that routine a little easier to handle?

2. WRT specifying all versions for lifecycle plugins, I'd suggest the use of
either (a) a lifecycle/packaging version that would specify each plugin's
version, as was suggested on the users@ list; or, (b) a new piece of syntax
to specify a set of plugin versions that are commonly used together. (A)
wouldn't make much sense unless we externalized all of our packagings,
IMO...which makes Maven sort of a lifeless hull without at least an initial
internet connection. (B) gets you into the realm of maybe making these
plugin-sets additive (specify multiple of them in the same POM), and maybe
allowing them to provide configuration, etc...which is a whole new can of
worms, I guess.

3. I think it's quite dangerous to keep on the track of having the common
user use the current RELEASE meta-versions. We have to get out of this [
1.0-2.0) mindset (where we're operating with basically the same feature-set
and no breaks in compatibility from release to release). RELEASE is
indiscriminate about compatibility rules, which means that any POM checked
in that relies on RELEASE meta-versions may break in the future. This is
compounded by the fact that new plugin versions are *never* detected unless
(a) the plugin hasn't been used before, and isn't in the local repository,
or (b) the user *chooses* to use -U...that means that for any two-member
development team, unless they're invoking -U in synchrony there is a real
potential for mismatched plugin versions.

Wayne, your experiences wouldn't seem to be very encouraging for the idea of
writing more/better documentation. Would a cheat-sheet or a FAQ that's
well-organized help with these sorts of newbie problems?

Dan/Carlos/Wayne/etc.: would it be reasonable to provide some nice plugins
(maybe with GUIs where we can) that will help users choose what they need?

Peter: WRT the parent POM residing in central, see my comment about the
externalized packaging/lifecycle definitions...that would make Maven itself
fairly limited if something happens on the network. Right now, it is
possible (maybe a little tough, but possible) to use Maven offline...with an
externalized parent, you'd have to have an update policy or a mechanism for
specifying the root POM version, which would land you in a tricky spot WRT
multimodule builds.

I'm sure I've missed out on someone's comments, but I think that pretty well
summarizes my thinking...

-john

On 4/12/07, Stephane Nicoll <st...@gmail.com> wrote:
>
> 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 <Pe...@fmr.com> 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:brianf@reply.infinity.nu]
> > 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Andrew Williams <an...@handyande.co.uk>]

Actually, that is an interesting point, it could include that.
Enterprise is aimed more at the development cycle, but that could  
easily include a "known stable and compatible with this toolset"  
maven release.

Andy

On 13 Apr 2007, at 14:01, David Roussel wrote:

>
> Hmm, that's a good idea.  A Maven distribution based on a given Maven
> release.  Is this like what "Maven Enterprise" will be?
>
>
> John Casey wrote:
>>
>> Sure, my only point was that without this (and the standard packaging
>> definitions) _nothing_ will work...it's just a gut-level  
>> uneasiness, not
>> necessarily a big problem.
>>
>> On a side note, I think it'd be neat to provide a maven distro  
>> that has a
>> small internal repo with the latest releases of the plugins in the  
>> pom and
>> jar lifecycles...maybe with the packaging/super-POM in there  
>> too...then,
>> you
>> could always override and get from central. That would make Maven  
>> almost
>> offline-proof right out of the box...
>>
>> -john
>>
>> On 4/12/07, Hayes, Peter <Pe...@fmr.com> wrote:
>>>
>>> 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:brianf@reply.infinity.nu]
>>> 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:stephane.nicoll@gmail.com]
>>> 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 <Pe...@fmr.com> 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:brianf@reply.infinity.nu]
>>>> 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: dev-unsubscribe@maven.apache.org For
>>>> additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------- 
>>>> --
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
>>>> additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> -------------------------------------------------------------------- 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For  
>>> additional
>>> commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>> -------------------------------------------------------------------- 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------------------- 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>>
>
> -- 
> View this message in context: http://www.nabble.com/Remove-auto- 
> resolution-of-plugin-versions-from-Maven-2.1- 
> tf3560617s177.html#a9978504
> Sent from the Maven Developers mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[David Roussel <na...@diroussel.xsmail.com>]

Hmm, that's a good idea.  A Maven distribution based on a given Maven
release.  Is this like what "Maven Enterprise" will be?


John Casey wrote:
> 
> Sure, my only point was that without this (and the standard packaging
> definitions) _nothing_ will work...it's just a gut-level uneasiness, not
> necessarily a big problem.
> 
> On a side note, I think it'd be neat to provide a maven distro that has a
> small internal repo with the latest releases of the plugins in the pom and
> jar lifecycles...maybe with the packaging/super-POM in there too...then,
> you
> could always override and get from central. That would make Maven almost
> offline-proof right out of the box...
> 
> -john
> 
> On 4/12/07, Hayes, Peter <Pe...@fmr.com> wrote:
>>
>> 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:brianf@reply.infinity.nu]
>> 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:stephane.nicoll@gmail.com]
>> 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 <Pe...@fmr.com> 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:brianf@reply.infinity.nu]
>> > 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: dev-unsubscribe@maven.apache.org For
>> > additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
>> > additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional
>> commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> 
> 

-- 
View this message in context: http://www.nabble.com/Remove-auto-resolution-of-plugin-versions-from-Maven-2.1-tf3560617s177.html#a9978504
Sent from the Maven Developers mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[John Casey <ca...@gmail.com>]

Sure, my only point was that without this (and the standard packaging
definitions) _nothing_ will work...it's just a gut-level uneasiness, not
necessarily a big problem.

On a side note, I think it'd be neat to provide a maven distro that has a
small internal repo with the latest releases of the plugins in the pom and
jar lifecycles...maybe with the packaging/super-POM in there too...then, you
could always override and get from central. That would make Maven almost
offline-proof right out of the box...

-john

On 4/12/07, Hayes, Peter <Pe...@fmr.com> wrote:
>
> 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:brianf@reply.infinity.nu]
> 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:stephane.nicoll@gmail.com]
> 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 <Pe...@fmr.com> 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:brianf@reply.infinity.nu]
> > 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: dev-unsubscribe@maven.apache.org For
> > additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> > additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional
> commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

RE: Remove auto-resolution of plugin versions from Maven 2.1

["Hayes, Peter" <Pe...@fmr.com>]

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:brianf@reply.infinity.nu] 
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:stephane.nicoll@gmail.com] 
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 <Pe...@fmr.com> 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:brianf@reply.infinity.nu]
> 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: dev-unsubscribe@maven.apache.org For 
> additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For 
> additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional commands, e-mail: dev-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Remove auto-resolution of plugin versions from Maven 2.1

["Brian E. Fox" <br...@reply.infinity.nu>]

Same here. 

-----Original Message-----
From: Stephane Nicoll [mailto:stephane.nicoll@gmail.com] 
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 <Pe...@fmr.com> 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:brianf@reply.infinity.nu]
> 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: dev-unsubscribe@maven.apache.org For 
> additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For 
> additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional commands, e-mail: dev-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Stephane Nicoll <st...@gmail.com>]

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 <Pe...@fmr.com> 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:brianf@reply.infinity.nu]
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Remove auto-resolution of plugin versions from Maven 2.1

["Hayes, Peter" <Pe...@fmr.com>]

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:brianf@reply.infinity.nu] 
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Remove auto-resolution of plugin versions from Maven 2.1

["Brian E. Fox" <br...@reply.infinity.nu>]

>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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Barrie Treloar <ba...@gmail.com>]

On 4/12/07, Carlos Sanchez <ca...@apache.org> 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 to workaround a known issue) then
I specify it in the the pom. Otherwise I want the latest.

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.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[David Roussel <na...@diroussel.xsmail.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.
> 

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 Maven 2.x.y.  If I do
specify a version, then I overrule.

This works fine for the standard plugins, but what about more exotic
plugins?  

We need a mechanism that is:
 - deterministic
 - simple for newbies
 - flexible for old hands
 
So if I'm writing spelling-checker-plugin how do we make it deterministic
when the user doesn't specify a version?  Since Maven doesn't know about my
plugin, I guess my plugin must know about maven.  I need some meta-data that
says:
 - for maven version <2.0.4 use  spelling-checker-plugin version 1.1
 - for maven version 2.0.5-2.0.6 use  spelling-checker-plugin version 1.2
 - otherwise use spelling-checker-plugin version 2.0

Perhaps this meta-data could in maven-metadata.xml and held in the
repository.  

How does that sound? 

Should this apply to all plugins, or just exotic ones?  Perhaps it should
apply 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.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Wayne Fay <wa...@gmail.com>]

I was merely speaking abstractly about "things that seem to lead new
Maven users down the wrong path" (towards failure rather than success
with Maven).

I have seen countless emails because someone didn't read the
directions and failed to configure their settings.xml with their web
proxy settings. Also countless emails because a new user is confused
about javax.* jars being unavailable on Central, while the rest of the
artifacts they need were downloaded OK.

My point is simply, if we require all users to specify all versions of
all plugins in their poms, this will be yet another thing that will
result in a significant quantity of emails to the Maven Users list
from new users who haven't bothered to read the instructions and are
attempting to build a pom for their project.

Wayne

On 4/11/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
> I don't see the connection between javax.* and the plugins?
>
> -----Original Message-----
> From: Wayne Fay [mailto:waynefay@gmail.com]
> 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 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 <da...@gmail.com> wrote:
> > 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 <ca...@apache.org> 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.
> > >
> > > On 4/11/07, John Casey <ca...@gmail.com> 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 enforcer-plugin would do it.
> > > >
> > > > I think we should write something into 2.1 that will allow a
> > > specification
> > > > of a "standard" plugin-version set, and use that for things like
> the
> > > > lifecycle plugins. Then, we could provide a default version for
> that
> > > > internally in the maven distro, and let users override it. Also,
> we
> > > could
> > > > use a plugin that will help users discover and select new versions
> for
> > > their
> > > > multimodule projects.
> > > >
> > > > Finally, I think we should probably allow configuration of
> something
> > > similar
> > > > to pluginManagement in the settings.xml, for cases where people
> are
> > > invoking
> > > > the plugin directly from the command line. This starts to look a
> little
> > > like
> > > > the old plugin registry, except that it would use syntax in common
> with
> > > the
> > > > POM, and this time we'd make sure it was bullet-proof before
> sending it
> > > out.
> > > >
> > > > I just think we need to make a serious effort to see what the
> > > shortcomings
> > > > of the 2.0.x design is in terms of what we're pushing --
> reproducible
> > > builds
> > > > -- and then figure out how to make that happen by default in 2.1.
> If we
> > > want
> > > > to support a migration path based on the modelVersion, that would
> make
> > > > sense, though I still think we should nag those users about the
> > > > unpredictability involved in that sort of build. Unfortunately, we
> don't
> > > > have a "developers" vs. "users" runtime profile, so users building
> that
> > > sort
> > > > of project would see the same warnings...
> > > >
> > > > -john
> > > >
> > > > On 4/11/07, Brett Porter <br...@apache.org> 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 override it, but I'd like to see plugin
> 'packs'
> > > > > as a better solution to reduce the amount of configuration
> needed).
> > > > >
> > > > > Thirdly, we need to think carefully about the impact on existing
> > > > > builds. We're not just impacting the people that wrote the build
> - we
> > > > > impact the random people that grab a project and unwittingly try
> and
> > > > > build it with 2.1 not knowing the author never tested that, and
> get
> > > > > the bad experience.
> > > > >
> > > > > I'm still in favour of a compatibility mode that can be driven
> by the
> > > > > prerequisites or the modelVersion. I say let people use the
> > > > > dependency plugin now to start fixing their builds, but for 2.1
> let
> > > > > them make the conscious decision to move up to this.
> > > > >
> > > > > - Brett
> > > > >
> > > > > On 12/04/2007, at 2:54 AM, 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 resolve RELEASE or LATEST
> meta-
> > > > > > versions
> > > > > > for plugins any more. I'd actually argue that this is bad
> practice
> > > > > > for ANY
> > > > > > artifact that is to be resolved, including site skins, etc.
> since
> > > > > > it kills
> > > > > > our ability to deprecate features.
> > > > > >
> > > > > > I'd like to completely remove this from the
> DefaultPluginManager in
> > > > > > trunk,
> > > > > > so we can start moving away from this practice immediately.
> > > > > >
> > > > > > I guess this is an informal vote on the subject, but I wanted
> to get
> > > > > > everyone's opinions before I move on it, since it's a fairly
> > > important
> > > > > > change.
> > > > > >
> > > > > > Here's my +1.
> > > > > >
> > > > > > -john
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > I could give you my word as a Spaniard.
> > > No good. I've known too many Spaniards.
> > >                             -- The Princess Bride
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Remove auto-resolution of plugin versions from Maven 2.1

["Brian E. Fox" <br...@reply.infinity.nu>]

I don't see the connection between javax.* and the plugins?

-----Original Message-----
From: Wayne Fay [mailto:waynefay@gmail.com] 
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 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 <da...@gmail.com> wrote:
> 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 <ca...@apache.org> 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.
> >
> > On 4/11/07, John Casey <ca...@gmail.com> 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 enforcer-plugin would do it.
> > >
> > > I think we should write something into 2.1 that will allow a
> > specification
> > > of a "standard" plugin-version set, and use that for things like
the
> > > lifecycle plugins. Then, we could provide a default version for
that
> > > internally in the maven distro, and let users override it. Also,
we
> > could
> > > use a plugin that will help users discover and select new versions
for
> > their
> > > multimodule projects.
> > >
> > > Finally, I think we should probably allow configuration of
something
> > similar
> > > to pluginManagement in the settings.xml, for cases where people
are
> > invoking
> > > the plugin directly from the command line. This starts to look a
little
> > like
> > > the old plugin registry, except that it would use syntax in common
with
> > the
> > > POM, and this time we'd make sure it was bullet-proof before
sending it
> > out.
> > >
> > > I just think we need to make a serious effort to see what the
> > shortcomings
> > > of the 2.0.x design is in terms of what we're pushing --
reproducible
> > builds
> > > -- and then figure out how to make that happen by default in 2.1.
If we
> > want
> > > to support a migration path based on the modelVersion, that would
make
> > > sense, though I still think we should nag those users about the
> > > unpredictability involved in that sort of build. Unfortunately, we
don't
> > > have a "developers" vs. "users" runtime profile, so users building
that
> > sort
> > > of project would see the same warnings...
> > >
> > > -john
> > >
> > > On 4/11/07, Brett Porter <br...@apache.org> 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 override it, but I'd like to see plugin
'packs'
> > > > as a better solution to reduce the amount of configuration
needed).
> > > >
> > > > Thirdly, we need to think carefully about the impact on existing
> > > > builds. We're not just impacting the people that wrote the build
- we
> > > > impact the random people that grab a project and unwittingly try
and
> > > > build it with 2.1 not knowing the author never tested that, and
get
> > > > the bad experience.
> > > >
> > > > I'm still in favour of a compatibility mode that can be driven
by the
> > > > prerequisites or the modelVersion. I say let people use the
> > > > dependency plugin now to start fixing their builds, but for 2.1
let
> > > > them make the conscious decision to move up to this.
> > > >
> > > > - Brett
> > > >
> > > > On 12/04/2007, at 2:54 AM, 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 resolve RELEASE or LATEST
meta-
> > > > > versions
> > > > > for plugins any more. I'd actually argue that this is bad
practice
> > > > > for ANY
> > > > > artifact that is to be resolved, including site skins, etc.
since
> > > > > it kills
> > > > > our ability to deprecate features.
> > > > >
> > > > > I'd like to completely remove this from the
DefaultPluginManager in
> > > > > trunk,
> > > > > so we can start moving away from this practice immediately.
> > > > >
> > > > > I guess this is an informal vote on the subject, but I wanted
to get
> > > > > everyone's opinions before I move on it, since it's a fairly
> > important
> > > > > change.
> > > > >
> > > > > Here's my +1.
> > > > >
> > > > > -john
> > > >
> > > >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> >                             -- The Princess Bride
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Wayne Fay <wa...@gmail.com>]

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 <da...@gmail.com> wrote:
> 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 <ca...@apache.org> 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.
> >
> > On 4/11/07, John Casey <ca...@gmail.com> 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 enforcer-plugin would do it.
> > >
> > > I think we should write something into 2.1 that will allow a
> > specification
> > > of a "standard" plugin-version set, and use that for things like the
> > > lifecycle plugins. Then, we could provide a default version for that
> > > internally in the maven distro, and let users override it. Also, we
> > could
> > > use a plugin that will help users discover and select new versions for
> > their
> > > multimodule projects.
> > >
> > > Finally, I think we should probably allow configuration of something
> > similar
> > > to pluginManagement in the settings.xml, for cases where people are
> > invoking
> > > the plugin directly from the command line. This starts to look a little
> > like
> > > the old plugin registry, except that it would use syntax in common with
> > the
> > > POM, and this time we'd make sure it was bullet-proof before sending it
> > out.
> > >
> > > I just think we need to make a serious effort to see what the
> > shortcomings
> > > of the 2.0.x design is in terms of what we're pushing -- reproducible
> > builds
> > > -- and then figure out how to make that happen by default in 2.1. If we
> > want
> > > to support a migration path based on the modelVersion, that would make
> > > sense, though I still think we should nag those users about the
> > > unpredictability involved in that sort of build. Unfortunately, we don't
> > > have a "developers" vs. "users" runtime profile, so users building that
> > sort
> > > of project would see the same warnings...
> > >
> > > -john
> > >
> > > On 4/11/07, Brett Porter <br...@apache.org> 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 override it, but I'd like to see plugin 'packs'
> > > > as a better solution to reduce the amount of configuration needed).
> > > >
> > > > Thirdly, we need to think carefully about the impact on existing
> > > > builds. We're not just impacting the people that wrote the build - we
> > > > impact the random people that grab a project and unwittingly try and
> > > > build it with 2.1 not knowing the author never tested that, and get
> > > > the bad experience.
> > > >
> > > > I'm still in favour of a compatibility mode that can be driven by the
> > > > prerequisites or the modelVersion. I say let people use the
> > > > dependency plugin now to start fixing their builds, but for 2.1 let
> > > > them make the conscious decision to move up to this.
> > > >
> > > > - Brett
> > > >
> > > > On 12/04/2007, at 2:54 AM, 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 resolve RELEASE or LATEST meta-
> > > > > versions
> > > > > for plugins any more. I'd actually argue that this is bad practice
> > > > > for ANY
> > > > > artifact that is to be resolved, including site skins, etc. since
> > > > > it kills
> > > > > our ability to deprecate features.
> > > > >
> > > > > I'd like to completely remove this from the DefaultPluginManager in
> > > > > trunk,
> > > > > so we can start moving away from this practice immediately.
> > > > >
> > > > > I guess this is an informal vote on the subject, but I wanted to get
> > > > > everyone's opinions before I move on it, since it's a fairly
> > important
> > > > > change.
> > > > >
> > > > > Here's my +1.
> > > > >
> > > > > -john
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> >                             -- The Princess Bride
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Mark Hobson <ma...@gmail.com>]

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 theoretically since it's a documented feature
[1] without an implementation [2] ;)

I started work on reimplementing this a while back and hopefully will
have some more time to finish it off soon.  Would this resolve this
problem if it became default behaviour?

Mark

[1] http://maven.apache.org/plugins/maven-release-plugin/examples/generate-release-poms.html
[2] http://jira.codehaus.org/browse/MRELEASE-177

On 12/04/07, Franz Allan Valencia See <fr...@gmail.com> wrote:
> 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 is directly using and his
> build will work most of the time. But if the resolution the user gets
> fails his / her build, then the user would have to go with the 'best'
> practice which is to specify all artifacts that his / her project
> needs.
>
> On 4/11/07, Dan Tran <da...@gmail.com> wrote:
> > 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 <ca...@apache.org> 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.
> > >
> > > On 4/11/07, John Casey <ca...@gmail.com> 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 enforcer-plugin would do it.
> > > >
> > > > I think we should write something into 2.1 that will allow a
> > > specification
> > > > of a "standard" plugin-version set, and use that for things like the
> > > > lifecycle plugins. Then, we could provide a default version for that
> > > > internally in the maven distro, and let users override it. Also, we
> > > could
> > > > use a plugin that will help users discover and select new versions for
> > > their
> > > > multimodule projects.
> > > >
> > > > Finally, I think we should probably allow configuration of something
> > > similar
> > > > to pluginManagement in the settings.xml, for cases where people are
> > > invoking
> > > > the plugin directly from the command line. This starts to look a little
> > > like
> > > > the old plugin registry, except that it would use syntax in common with
> > > the
> > > > POM, and this time we'd make sure it was bullet-proof before sending it
> > > out.
> > > >
> > > > I just think we need to make a serious effort to see what the
> > > shortcomings
> > > > of the 2.0.x design is in terms of what we're pushing -- reproducible
> > > builds
> > > > -- and then figure out how to make that happen by default in 2.1. If we
> > > want
> > > > to support a migration path based on the modelVersion, that would make
> > > > sense, though I still think we should nag those users about the
> > > > unpredictability involved in that sort of build. Unfortunately, we don't
> > > > have a "developers" vs. "users" runtime profile, so users building that
> > > sort
> > > > of project would see the same warnings...
> > > >
> > > > -john
> > > >
> > > > On 4/11/07, Brett Porter <br...@apache.org> 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 override it, but I'd like to see plugin 'packs'
> > > > > as a better solution to reduce the amount of configuration needed).
> > > > >
> > > > > Thirdly, we need to think carefully about the impact on existing
> > > > > builds. We're not just impacting the people that wrote the build - we
> > > > > impact the random people that grab a project and unwittingly try and
> > > > > build it with 2.1 not knowing the author never tested that, and get
> > > > > the bad experience.
> > > > >
> > > > > I'm still in favour of a compatibility mode that can be driven by the
> > > > > prerequisites or the modelVersion. I say let people use the
> > > > > dependency plugin now to start fixing their builds, but for 2.1 let
> > > > > them make the conscious decision to move up to this.
> > > > >
> > > > > - Brett
> > > > >
> > > > > On 12/04/2007, at 2:54 AM, 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 resolve RELEASE or LATEST meta-
> > > > > > versions
> > > > > > for plugins any more. I'd actually argue that this is bad practice
> > > > > > for ANY
> > > > > > artifact that is to be resolved, including site skins, etc. since
> > > > > > it kills
> > > > > > our ability to deprecate features.
> > > > > >
> > > > > > I'd like to completely remove this from the DefaultPluginManager in
> > > > > > trunk,
> > > > > > so we can start moving away from this practice immediately.
> > > > > >
> > > > > > I guess this is an informal vote on the subject, but I wanted to get
> > > > > > everyone's opinions before I move on it, since it's a fairly
> > > important
> > > > > > change.
> > > > > >
> > > > > > Here's my +1.
> > > > > >
> > > > > > -john
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > I could give you my word as a Spaniard.
> > > No good. I've known too many Spaniards.
> > >                             -- The Princess Bride
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Franz Allan Valencia See <fr...@gmail.com>]

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 is directly using and his
build will work most of the time. But if the resolution the user gets
fails his / her build, then the user would have to go with the 'best'
practice which is to specify all artifacts that his / her project
needs.

On 4/11/07, Dan Tran <da...@gmail.com> wrote:
> 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 <ca...@apache.org> 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.
> >
> > On 4/11/07, John Casey <ca...@gmail.com> 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 enforcer-plugin would do it.
> > >
> > > I think we should write something into 2.1 that will allow a
> > specification
> > > of a "standard" plugin-version set, and use that for things like the
> > > lifecycle plugins. Then, we could provide a default version for that
> > > internally in the maven distro, and let users override it. Also, we
> > could
> > > use a plugin that will help users discover and select new versions for
> > their
> > > multimodule projects.
> > >
> > > Finally, I think we should probably allow configuration of something
> > similar
> > > to pluginManagement in the settings.xml, for cases where people are
> > invoking
> > > the plugin directly from the command line. This starts to look a little
> > like
> > > the old plugin registry, except that it would use syntax in common with
> > the
> > > POM, and this time we'd make sure it was bullet-proof before sending it
> > out.
> > >
> > > I just think we need to make a serious effort to see what the
> > shortcomings
> > > of the 2.0.x design is in terms of what we're pushing -- reproducible
> > builds
> > > -- and then figure out how to make that happen by default in 2.1. If we
> > want
> > > to support a migration path based on the modelVersion, that would make
> > > sense, though I still think we should nag those users about the
> > > unpredictability involved in that sort of build. Unfortunately, we don't
> > > have a "developers" vs. "users" runtime profile, so users building that
> > sort
> > > of project would see the same warnings...
> > >
> > > -john
> > >
> > > On 4/11/07, Brett Porter <br...@apache.org> 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 override it, but I'd like to see plugin 'packs'
> > > > as a better solution to reduce the amount of configuration needed).
> > > >
> > > > Thirdly, we need to think carefully about the impact on existing
> > > > builds. We're not just impacting the people that wrote the build - we
> > > > impact the random people that grab a project and unwittingly try and
> > > > build it with 2.1 not knowing the author never tested that, and get
> > > > the bad experience.
> > > >
> > > > I'm still in favour of a compatibility mode that can be driven by the
> > > > prerequisites or the modelVersion. I say let people use the
> > > > dependency plugin now to start fixing their builds, but for 2.1 let
> > > > them make the conscious decision to move up to this.
> > > >
> > > > - Brett
> > > >
> > > > On 12/04/2007, at 2:54 AM, 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 resolve RELEASE or LATEST meta-
> > > > > versions
> > > > > for plugins any more. I'd actually argue that this is bad practice
> > > > > for ANY
> > > > > artifact that is to be resolved, including site skins, etc. since
> > > > > it kills
> > > > > our ability to deprecate features.
> > > > >
> > > > > I'd like to completely remove this from the DefaultPluginManager in
> > > > > trunk,
> > > > > so we can start moving away from this practice immediately.
> > > > >
> > > > > I guess this is an informal vote on the subject, but I wanted to get
> > > > > everyone's opinions before I move on it, since it's a fairly
> > important
> > > > > change.
> > > > >
> > > > > Here's my +1.
> > > > >
> > > > > -john
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> >                             -- The Princess Bride
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Dan Tran <da...@gmail.com>]

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 <ca...@apache.org> 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.
>
> On 4/11/07, John Casey <ca...@gmail.com> 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 enforcer-plugin would do it.
> >
> > I think we should write something into 2.1 that will allow a
> specification
> > of a "standard" plugin-version set, and use that for things like the
> > lifecycle plugins. Then, we could provide a default version for that
> > internally in the maven distro, and let users override it. Also, we
> could
> > use a plugin that will help users discover and select new versions for
> their
> > multimodule projects.
> >
> > Finally, I think we should probably allow configuration of something
> similar
> > to pluginManagement in the settings.xml, for cases where people are
> invoking
> > the plugin directly from the command line. This starts to look a little
> like
> > the old plugin registry, except that it would use syntax in common with
> the
> > POM, and this time we'd make sure it was bullet-proof before sending it
> out.
> >
> > I just think we need to make a serious effort to see what the
> shortcomings
> > of the 2.0.x design is in terms of what we're pushing -- reproducible
> builds
> > -- and then figure out how to make that happen by default in 2.1. If we
> want
> > to support a migration path based on the modelVersion, that would make
> > sense, though I still think we should nag those users about the
> > unpredictability involved in that sort of build. Unfortunately, we don't
> > have a "developers" vs. "users" runtime profile, so users building that
> sort
> > of project would see the same warnings...
> >
> > -john
> >
> > On 4/11/07, Brett Porter <br...@apache.org> 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 override it, but I'd like to see plugin 'packs'
> > > as a better solution to reduce the amount of configuration needed).
> > >
> > > Thirdly, we need to think carefully about the impact on existing
> > > builds. We're not just impacting the people that wrote the build - we
> > > impact the random people that grab a project and unwittingly try and
> > > build it with 2.1 not knowing the author never tested that, and get
> > > the bad experience.
> > >
> > > I'm still in favour of a compatibility mode that can be driven by the
> > > prerequisites or the modelVersion. I say let people use the
> > > dependency plugin now to start fixing their builds, but for 2.1 let
> > > them make the conscious decision to move up to this.
> > >
> > > - Brett
> > >
> > > On 12/04/2007, at 2:54 AM, 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 resolve RELEASE or LATEST meta-
> > > > versions
> > > > for plugins any more. I'd actually argue that this is bad practice
> > > > for ANY
> > > > artifact that is to be resolved, including site skins, etc. since
> > > > it kills
> > > > our ability to deprecate features.
> > > >
> > > > I'd like to completely remove this from the DefaultPluginManager in
> > > > trunk,
> > > > so we can start moving away from this practice immediately.
> > > >
> > > > I guess this is an informal vote on the subject, but I wanted to get
> > > > everyone's opinions before I move on it, since it's a fairly
> important
> > > > change.
> > > >
> > > > Here's my +1.
> > > >
> > > > -john
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>                             -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Carlos Sanchez <ca...@apache.org>]

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 <ca...@gmail.com> 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 enforcer-plugin would do it.
>
> I think we should write something into 2.1 that will allow a specification
> of a "standard" plugin-version set, and use that for things like the
> lifecycle plugins. Then, we could provide a default version for that
> internally in the maven distro, and let users override it. Also, we could
> use a plugin that will help users discover and select new versions for their
> multimodule projects.
>
> Finally, I think we should probably allow configuration of something similar
> to pluginManagement in the settings.xml, for cases where people are invoking
> the plugin directly from the command line. This starts to look a little like
> the old plugin registry, except that it would use syntax in common with the
> POM, and this time we'd make sure it was bullet-proof before sending it out.
>
> I just think we need to make a serious effort to see what the shortcomings
> of the 2.0.x design is in terms of what we're pushing -- reproducible builds
> -- and then figure out how to make that happen by default in 2.1. If we want
> to support a migration path based on the modelVersion, that would make
> sense, though I still think we should nag those users about the
> unpredictability involved in that sort of build. Unfortunately, we don't
> have a "developers" vs. "users" runtime profile, so users building that sort
> of project would see the same warnings...
>
> -john
>
> On 4/11/07, Brett Porter <br...@apache.org> 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 override it, but I'd like to see plugin 'packs'
> > as a better solution to reduce the amount of configuration needed).
> >
> > Thirdly, we need to think carefully about the impact on existing
> > builds. We're not just impacting the people that wrote the build - we
> > impact the random people that grab a project and unwittingly try and
> > build it with 2.1 not knowing the author never tested that, and get
> > the bad experience.
> >
> > I'm still in favour of a compatibility mode that can be driven by the
> > prerequisites or the modelVersion. I say let people use the
> > dependency plugin now to start fixing their builds, but for 2.1 let
> > them make the conscious decision to move up to this.
> >
> > - Brett
> >
> > On 12/04/2007, at 2:54 AM, 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 resolve RELEASE or LATEST meta-
> > > versions
> > > for plugins any more. I'd actually argue that this is bad practice
> > > for ANY
> > > artifact that is to be resolved, including site skins, etc. since
> > > it kills
> > > our ability to deprecate features.
> > >
> > > I'd like to completely remove this from the DefaultPluginManager in
> > > trunk,
> > > so we can start moving away from this practice immediately.
> > >
> > > I guess this is an informal vote on the subject, but I wanted to get
> > > everyone's opinions before I move on it, since it's a fairly important
> > > change.
> > >
> > > Here's my +1.
> > >
> > > -john
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Jerome Lacoste <je...@gmail.com>]

On 4/11/07, John Casey <ca...@gmail.com> 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 enforcer-plugin would do it.

Turning this idea around, wouldn't it be possible to force an update
of the POM to make it compatible with 2.1 ?

That way, people cannot use 2.1 without willingly marking their POM.
Those who build a project made for 2.0.x with 2.1 get an error or
warning.

Probably not for a 2.x release, and probably not wanted as not
completely backwards compatible but just an idea.

J

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[John Casey <ca...@gmail.com>]

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 something into 2.1 that will allow a specification
of a "standard" plugin-version set, and use that for things like the
lifecycle plugins. Then, we could provide a default version for that
internally in the maven distro, and let users override it. Also, we could
use a plugin that will help users discover and select new versions for their
multimodule projects.

Finally, I think we should probably allow configuration of something similar
to pluginManagement in the settings.xml, for cases where people are invoking
the plugin directly from the command line. This starts to look a little like
the old plugin registry, except that it would use syntax in common with the
POM, and this time we'd make sure it was bullet-proof before sending it out.

I just think we need to make a serious effort to see what the shortcomings
of the 2.0.x design is in terms of what we're pushing -- reproducible builds
-- and then figure out how to make that happen by default in 2.1. If we want
to support a migration path based on the modelVersion, that would make
sense, though I still think we should nag those users about the
unpredictability involved in that sort of build. Unfortunately, we don't
have a "developers" vs. "users" runtime profile, so users building that sort
of project would see the same warnings...

-john

On 4/11/07, Brett Porter <br...@apache.org> 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 override it, but I'd like to see plugin 'packs'
> as a better solution to reduce the amount of configuration needed).
>
> Thirdly, we need to think carefully about the impact on existing
> builds. We're not just impacting the people that wrote the build - we
> impact the random people that grab a project and unwittingly try and
> build it with 2.1 not knowing the author never tested that, and get
> the bad experience.
>
> I'm still in favour of a compatibility mode that can be driven by the
> prerequisites or the modelVersion. I say let people use the
> dependency plugin now to start fixing their builds, but for 2.1 let
> them make the conscious decision to move up to this.
>
> - Brett
>
> On 12/04/2007, at 2:54 AM, 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 resolve RELEASE or LATEST meta-
> > versions
> > for plugins any more. I'd actually argue that this is bad practice
> > for ANY
> > artifact that is to be resolved, including site skins, etc. since
> > it kills
> > our ability to deprecate features.
> >
> > I'd like to completely remove this from the DefaultPluginManager in
> > trunk,
> > so we can start moving away from this practice immediately.
> >
> > I guess this is an informal vote on the subject, but I wanted to get
> > everyone's opinions before I move on it, since it's a fairly important
> > change.
> >
> > Here's my +1.
> >
> > -john
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Brett Porter <br...@apache.org>]

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 like to see plugin 'packs'  
as a better solution to reduce the amount of configuration needed).

Thirdly, we need to think carefully about the impact on existing  
builds. We're not just impacting the people that wrote the build - we  
impact the random people that grab a project and unwittingly try and  
build it with 2.1 not knowing the author never tested that, and get  
the bad experience.

I'm still in favour of a compatibility mode that can be driven by the  
prerequisites or the modelVersion. I say let people use the  
dependency plugin now to start fixing their builds, but for 2.1 let  
them make the conscious decision to move up to this.

- Brett

On 12/04/2007, at 2:54 AM, 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 resolve RELEASE or LATEST meta- 
> versions
> for plugins any more. I'd actually argue that this is bad practice  
> for ANY
> artifact that is to be resolved, including site skins, etc. since  
> it kills
> our ability to deprecate features.
>
> I'd like to completely remove this from the DefaultPluginManager in  
> trunk,
> so we can start moving away from this practice immediately.
>
> I guess this is an informal vote on the subject, but I wanted to get
> everyone's opinions before I move on it, since it's a fairly important
> change.
>
> Here's my +1.
>
> -john

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[johne <je...@yahoo.com>]

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 of functionality.   RELEASE/SNAPSHOT could be
based on what was available no later then that timestamp.  Though it is
possible to provide a default timestamp with each release, I would think
that getting the latest would be best if there is none manually provided.

I would suggest that in doing this, that manual version 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 Developers mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Remove auto-resolution of plugin versions from Maven 2.1

[jallen <jo...@hotmail.com>]

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 even my shell is a dependency to be
managed (mid-90s multi-platform C++ coming back to haunt me). As others have
said I think migration and upgrade scenarios are better supported by tools,
plugins and docs, not inference and discovery (and by this i mean a plugin
that tells you what is potentially available for upgrade)

J


Brian E. Fox wrote:
> 
> 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-4).
> 
> Pom binding:
> -Same as dependencies. That is you may omit a version in your pom,
> provided it is set in pluginManagement. If not, the build fails. I'm on
> the fence if RELEASE should be allowed in place of a pinned version (but
> still must me listed in the POM, can't be assumed). I'm leaning towards
> no. 
> 
> 
> In my corp builds, this is effectively what I do now. Anything used
> anywhere in my poms is placed into pluginManagement. Any other plugin I
> may use sporadically on the CLI, I just get what's out there. I don't
> have any formal part of my build that requires any CLI invocation
> anyway, it's all bound to the poms so a "mvn install" or "mvn deploy"
> produces everything official. (including assemblies that use
> assembly:attach on pom projects made for that purpose) This means that
> anything not already set in pluginMgt is just for info like help:xxx
> etc.
> 
> I don't see large plugin packages as being particularly usefull for this
> problem. Just not assuming RELEASE in a pom binding should solve it.
> Trying to coordinate plugin packages together will be a large effort and
> people will probably just start listing individual numbers 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:casey.john.d@gmail.com] 
> Sent: Wednesday, April 11, 2007 12:55 PM
> To: Maven Developers List
> Subject: Remove auto-resolution of plugin versions from Maven 2.1
> 
> 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 for plugins any more. I'd actually argue that this is bad
> practice for ANY artifact that is to be resolved, including site skins,
> etc. since it kills our ability to deprecate features.
> 
> I'd like to completely remove this from the DefaultPluginManager in
> trunk, so we can start moving away from this practice immediately.
> 
> I guess this is an informal vote on the subject, but I wanted to get
> everyone's opinions before I move on it, since it's a fairly important
> change.
> 
> Here's my +1.
> 
> -john
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Remove-auto-resolution-of-plugin-versions-from-Maven-2.1-tf3560617s177.html#a9970386
Sent from the Maven Developers mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Remove auto-resolution of plugin versions from Maven 2.1

["Brian E. Fox" <br...@reply.infinity.nu>]

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-4).

Pom binding:
-Same as dependencies. That is you may omit a version in your pom,
provided it is set in pluginManagement. If not, the build fails. I'm on
the fence if RELEASE should be allowed in place of a pinned version (but
still must me listed in the POM, can't be assumed). I'm leaning towards
no. 


In my corp builds, this is effectively what I do now. Anything used
anywhere in my poms is placed into pluginManagement. Any other plugin I
may use sporadically on the CLI, I just get what's out there. I don't
have any formal part of my build that requires any CLI invocation
anyway, it's all bound to the poms so a "mvn install" or "mvn deploy"
produces everything official. (including assemblies that use
assembly:attach on pom projects made for that purpose) This means that
anything not already set in pluginMgt is just for info like help:xxx
etc.

I don't see large plugin packages as being particularly usefull for this
problem. Just not assuming RELEASE in a pom binding should solve it.
Trying to coordinate plugin packages together will be a large effort and
people will probably just start listing individual numbers 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:casey.john.d@gmail.com] 
Sent: Wednesday, April 11, 2007 12:55 PM
To: Maven Developers List
Subject: Remove auto-resolution of plugin versions from Maven 2.1

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 for plugins any more. I'd actually argue that this is bad
practice for ANY artifact that is to be resolved, including site skins,
etc. since it kills our ability to deprecate features.

I'd like to completely remove this from the DefaultPluginManager in
trunk, so we can start moving away from this practice immediately.

I guess this is an informal vote on the subject, but I wanted to get
everyone's opinions before I move on it, since it's a fairly important
change.

Here's my +1.

-john

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Remove auto-resolution of plugin versions from Maven 2.1

["Clark, Gil W." <Gi...@intuit.com>]

So, let me see if I understand:

- Assigning arbitrary quality levels is hard to do.  I agree.
- Linking the version selection process to something quantitative like test results and coverage results is better.  I also agree but this seems a ways off.  The interface between test reporting and whatever sets the metadata used by version selection will have to happen somehow.

Sounds like a case for a plugin perhaps.  After the test phase this plugin (tailored to whatever testing system one is using) would make a pass at the test results and then assign a quality attribute in the metadata.  Then, during version selection that quality attribute is examined depending on what the user is wanting to select.



-----Original Message-----
From: Jason van Zyl [mailto:jason@maven.org] 
Sent: Tuesday, May 01, 2007 4:53 PM
To: Maven Developers List
Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1


On 1 May 07, at 5:37 PM 1 May 07, Clark, Gil W. wrote:

> I know I'm getting into iffy territory here and my thoughts on this 
> were kind of rejected on the users list but I think that if the 
> version selection algorithm were to include some sort of quality 
> identifier it would solve some of these problems.
>
> The idea here is that some folks are going to want "latest"  
> regardless of the quality of the latest while others are going to want 
> the latest, highest quality release of a plug-in or
> component.  This can be used in conjunction with a version range.   
> So I could say <version>[1.0-STABLE, 2.0-STABLE)</version> and I'd 
> only get stable releases.  Or I could say <version>[1.0-WORKING, 
> 2.0-STABLE)</version> and I'd get defaulted to STABLE as long as there 
> is a stable version within the numeric range or if none exists I'd get 
> WORKING if a version at that quality level falls in the range.  Or I 
> could say <version>WORKING</version> if I only want the absolute 
> latest working version of a component - kind of like SNAPSHOT.
>
> This allows a POM to be targeted at a particular level of quality  
> while still leaving it open to select from a range of versions.   
> For final releases of a project good practice dictates the version 
> numbers be locked down for all dependencies.  That does mean modifying 
> the POM but that seems unavoidable.
>
> Of course, there may be multiple levels of quality like WORKING, 
> TESTED, FOO, RELEASE, etc.  This is the way Ivy works.
>

Maven has the notion of pluggable version transformations. This is  
the mechanism which looks at the token "SNAPSHOT" and performs the  
necessary logic to examine the metadata and retrieve the last built  
version. It's technically not hard to look at an arbitrary token and  
perform some logic to change the version that is slotted in.

The problem here is not a technical one of allowing any token, the  
problem is that what these things mean to people and the process they  
go through to arrive to determine the meaning will be arbitrary.

I think what people really want here is "something that has some  
functional improvements but are binary compatible with what I'm using".

What "WORKING", or "RELEASE" means vary. Especially in the case of a  
release as people currently have different processes.

We have already standard testing patterns and surefire, and we are  
starting to see standard release procedures so what we want to move  
toward is the use of ranges which would be good but coupled with some  
criteria for quality. So you would simply say I want [1.0,) which is  
anything 1.0 or above that 1) is binary compatible with what I used  
last time (we go and find the last release and see what version was  
resolved), and 2) has the same or better coverage. This is the only  
way you can deterministically be safe of picking something further  
down in a range.

Who's going to assign these arbitrary labels to releases? I mean who  
is doing this for Ivy? This stuff cannot be tacked on by the third  
party it simply is not scalable. Maven has the social capital (the  
necessary mass of users doing the same thing) to pull off these  
coverage and binary compatibility standards to make this transparent.  
That being said I still think people would benefit more from a daily  
report produced from a build server that pulled in new versions of  
dependencies that purport to work and actually run your tests. If  
successful then you click a button and your POMs are upgrade. The  
computer should do the crap work. We are really not that far away  
from something like this.

> The hardest part in all this is standardizing on these quality  
> levels - t

Bingo. This can only happen in a community like Maven where we have  
striven for standard everything from day one because this is the only  
way these types of things are possible. This will never be possible  
using Ant with Ivy, it was never the goal of Ant. They might say they  
can but that will require the addition of everything we already have.  
Then it will be converging toward what Maven actually is. The key  
difference is that Maven from day one was designed to have a complete  
and holistic approach to solving problems like this.

For example right now for releases, using the profile we have  
created, we require PGP signatures, javadocs, sources, and the  
licenses and notice files are inserted automatically (with the  
available overriding for cases where the metadata is insufficient).  
As our profile spreads into common use we can then also mixin Clirr  
to produce a small file indicating the level of binary compatibility,  
and a file indicating coverage. Even if this was not done in the  
original build we can inject those plugins for the release. How?  
Because all our builds are the same. Intervention on our part, but  
entirely scalable because of the common structure of our projects. I  
don't think many people using Maven, let alone detractors understand  
the power and utility of our model. We let the computer do what it'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:herve.boutemy@free.fr]
> 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 :
>> On 5/1/07, Hervé BOUTEMY <he...@free.fr> 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 too radical.
>>>
>>> such a LATEST option would be very usefull, not only for plugins but
>>> for every dependencies, to do regression testing against latest
>>> development version of everything. It would be like if Gump was
>>> integrated into
>>> Maven:
>>> http://gump.apache.org/
>>>
>>> I think we would need to differentiate plugin latest from
>>> dependencies latest.
>>
>> This LATEST thing is already in jira:
>> http://jira.codehaus.org/browse/MNG-2431 And I think it would be very
>> useful, both for plugins and for 'normal dependencies'.
> not exactly:
> - LATEST STABLE is not LATEST : LATEST doesn't try to differentiate  
> STABLE or not, just get any change to check ASAP if it breaks  
> something
> - "mvn -L" is on the command line, not in the pom : the pom refers  
> to chosen versions, for normal builds, but "mvn -L" is for  
> continuous builds, overriding chosen versions of the pom, to check  
> if a dependency has an evolution that will break something. The  
> artifact built with "mvn -L" is not intended for use, but only as a  
> pro-active test against dependencies evolution
>
>>
>> Regards,
>> Tomek
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
>> additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For  
> additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Jason van Zyl <ja...@maven.org>]

On 1 May 07, at 5:37 PM 1 May 07, Clark, Gil W. wrote:

> I know I'm getting into iffy territory here and my thoughts on this  
> were kind of rejected on the users list but I think that if the  
> version selection algorithm were to include some sort of quality  
> identifier it would solve some of these problems.
>
> The idea here is that some folks are going to want "latest"  
> regardless of the quality of the latest while others are going to  
> want the latest, highest quality release of a plug-in or  
> component.  This can be used in conjunction with a version range.   
> So I could say <version>[1.0-STABLE, 2.0-STABLE)</version> and I'd  
> only get stable releases.  Or I could say <version>[1.0-WORKING,  
> 2.0-STABLE)</version> and I'd get defaulted to STABLE as long as  
> there is a stable version within the numeric range or if none  
> exists I'd get WORKING if a version at that quality level falls in  
> the range.  Or I could say <version>WORKING</version> if I only  
> want the absolute latest working version of a component - kind of  
> like SNAPSHOT.
>
> This allows a POM to be targeted at a particular level of quality  
> while still leaving it open to select from a range of versions.   
> For final releases of a project good practice dictates the version  
> numbers be locked down for all dependencies.  That does mean  
> modifying the POM but that seems unavoidable.
>
> Of course, there may be multiple levels of quality like WORKING,  
> TESTED, FOO, RELEASE, etc.  This is the way Ivy works.
>

Maven has the notion of pluggable version transformations. This is  
the mechanism which looks at the token "SNAPSHOT" and performs the  
necessary logic to examine the metadata and retrieve the last built  
version. It's technically not hard to look at an arbitrary token and  
perform some logic to change the version that is slotted in.

The problem here is not a technical one of allowing any token, the  
problem is that what these things mean to people and the process they  
go through to arrive to determine the meaning will be arbitrary.

I think what people really want here is "something that has some  
functional improvements but are binary compatible with what I'm using".

What "WORKING", or "RELEASE" means vary. Especially in the case of a  
release as people currently have different processes.

We have already standard testing patterns and surefire, and we are  
starting to see standard release procedures so what we want to move  
toward is the use of ranges which would be good but coupled with some  
criteria for quality. So you would simply say I want [1.0,) which is  
anything 1.0 or above that 1) is binary compatible with what I used  
last time (we go and find the last release and see what version was  
resolved), and 2) has the same or better coverage. This is the only  
way you can deterministically be safe of picking something further  
down in a range.

Who's going to assign these arbitrary labels to releases? I mean who  
is doing this for Ivy? This stuff cannot be tacked on by the third  
party it simply is not scalable. Maven has the social capital (the  
necessary mass of users doing the same thing) to pull off these  
coverage and binary compatibility standards to make this transparent.  
That being said I still think people would benefit more from a daily  
report produced from a build server that pulled in new versions of  
dependencies that purport to work and actually run your tests. If  
successful then you click a button and your POMs are upgrade. The  
computer should do the crap work. We are really not that far away  
from something like this.

> The hardest part in all this is standardizing on these quality  
> levels - t

Bingo. This can only happen in a community like Maven where we have  
striven for standard everything from day one because this is the only  
way these types of things are possible. This will never be possible  
using Ant with Ivy, it was never the goal of Ant. They might say they  
can but that will require the addition of everything we already have.  
Then it will be converging toward what Maven actually is. The key  
difference is that Maven from day one was designed to have a complete  
and holistic approach to solving problems like this.

For example right now for releases, using the profile we have  
created, we require PGP signatures, javadocs, sources, and the  
licenses and notice files are inserted automatically (with the  
available overriding for cases where the metadata is insufficient).  
As our profile spreads into common use we can then also mixin Clirr  
to produce a small file indicating the level of binary compatibility,  
and a file indicating coverage. Even if this was not done in the  
original build we can inject those plugins for the release. How?  
Because all our builds are the same. Intervention on our part, but  
entirely scalable because of the common structure of our projects. I  
don't think many people using Maven, let alone detractors understand  
the power and utility of our model. We let the computer do what it'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:herve.boutemy@free.fr]
> 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 :
>> On 5/1/07, Hervé BOUTEMY <he...@free.fr> 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 too radical.
>>>
>>> such a LATEST option would be very usefull, not only for plugins but
>>> for every dependencies, to do regression testing against latest
>>> development version of everything. It would be like if Gump was
>>> integrated into
>>> Maven:
>>> http://gump.apache.org/
>>>
>>> I think we would need to differentiate plugin latest from
>>> dependencies latest.
>>
>> This LATEST thing is already in jira:
>> http://jira.codehaus.org/browse/MNG-2431 And I think it would be very
>> useful, both for plugins and for 'normal dependencies'.
> not exactly:
> - LATEST STABLE is not LATEST : LATEST doesn't try to differentiate  
> STABLE or not, just get any change to check ASAP if it breaks  
> something
> - "mvn -L" is on the command line, not in the pom : the pom refers  
> to chosen versions, for normal builds, but "mvn -L" is for  
> continuous builds, overriding chosen versions of the pom, to check  
> if a dependency has an evolution that will break something. The  
> artifact built with "mvn -L" is not intended for use, but only as a  
> pro-active test against dependencies evolution
>
>>
>> Regards,
>> Tomek
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
>> additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For  
> additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Remove auto-resolution of plugin versions from Maven 2.1

["Clark, Gil W." <Gi...@intuit.com>]

I know I'm getting into iffy territory here and my thoughts on this were kind of rejected on the users list but I think that if the version selection algorithm were to include some sort of quality identifier it would solve some of these problems.

The idea here is that some folks are going to want "latest" regardless of the quality of the latest while others are going to want the latest, highest quality release of a plug-in or component.  This can be used in conjunction with a version range.  So I could say <version>[1.0-STABLE, 2.0-STABLE)</version> and I'd only get stable releases.  Or I could say <version>[1.0-WORKING, 2.0-STABLE)</version> and I'd get defaulted to STABLE as long as there is a stable version within the numeric range or if none exists I'd get WORKING if a version at that quality level falls in the range.  Or I could say <version>WORKING</version> if I only want the absolute latest working version of a component - kind of like SNAPSHOT.

This allows a POM to be targeted at a particular level of quality while still leaving it open to select from a range of versions.  For final releases of a project good practice dictates the version numbers be locked down for all dependencies.  That does mean modifying the POM but that seems unavoidable.

Of course, there may be multiple levels of quality like WORKING, TESTED, FOO, RELEASE, etc.  This is the way Ivy works.

The hardest part in all this is standardizing on these quality levels - they can be dynamic - specified in the settings file or top level POM...




-----Original Message-----
From: Hervé BOUTEMY [mailto:herve.boutemy@free.fr] 
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 :
> On 5/1/07, Hervé BOUTEMY <he...@free.fr> 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 too radical.
> >
> > such a LATEST option would be very usefull, not only for plugins but 
> > for every dependencies, to do regression testing against latest 
> > development version of everything. It would be like if Gump was 
> > integrated into
> > Maven:
> > http://gump.apache.org/
> >
> > I think we would need to differentiate plugin latest from 
> > dependencies latest.
>
> This LATEST thing is already in jira:
> http://jira.codehaus.org/browse/MNG-2431 And I think it would be very 
> useful, both for plugins and for 'normal dependencies'.
not exactly:
- LATEST STABLE is not LATEST : LATEST doesn't try to differentiate STABLE or not, just get any change to check ASAP if it breaks something
- "mvn -L" is on the command line, not in the pom : the pom refers to chosen versions, for normal builds, but "mvn -L" is for continuous builds, overriding chosen versions of the pom, to check if a dependency has an evolution that will break something. The artifact built with "mvn -L" is not intended for use, but only as a pro-active test against dependencies evolution

>
> Regards,
> Tomek
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For 
> additional commands, e-mail: dev-help@maven.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional commands, e-mail: dev-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Hervé BOUTEMY <he...@free.fr>]

Le mardi 1 mai 2007, Tomasz Pik a écrit :
> On 5/1/07, Hervé BOUTEMY <he...@free.fr> 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 too radical.
> >
> > such a LATEST option would be very usefull, not only for plugins but for
> > every dependencies, to do regression testing against latest development
> > version of everything. It would be like if Gump was integrated into
> > Maven:
> > http://gump.apache.org/
> >
> > I think we would need to differentiate plugin latest from dependencies
> > latest.
>
> This LATEST thing is already in jira:
> http://jira.codehaus.org/browse/MNG-2431 And I think it would be very
> useful, both for plugins and for 'normal dependencies'.
not exactly:
- LATEST STABLE is not LATEST : LATEST doesn't try to differentiate STABLE or 
not, just get any change to check ASAP if it breaks something
- "mvn -L" is on the command line, not in the pom : the pom refers to chosen 
versions, for normal builds, but "mvn -L" is for continuous builds, 
overriding chosen versions of the pom, to check if a dependency has an 
evolution that will break something. The artifact built with "mvn -L" is not 
intended for use, but only as a pro-active test against dependencies 
evolution

>
> Regards,
> Tomek
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Jerome Lacoste <je...@gmail.com>]

On 5/1/07, Brian E. Fox <br...@reply.infinity.nu> 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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Remove auto-resolution of plugin versions from Maven 2.1

["Brian E. Fox" <br...@reply.infinity.nu>]

How on earth would you ever debug the inevitable issues when you suddenly upgrade to all new versions of plugins (and worse dependencies?)?
 

-----Original Message-----
From: Hervé BOUTEMY [mailto:herve.boutemy@free.fr] 
Sent: Tuesday, May 01, 2007 4:18 AM
To: Maven Developers List
Subject: Re: 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 ? Maybe too radical.
such a LATEST option would be very usefull, not only for plugins but for every dependencies, to do regression testing against latest development version of everything. It would be like if Gump was integrated into Maven: 
http://gump.apache.org/

I think we would need to differentiate plugin latest from dependencies latest.

Hervé

>
> Cheers,
>
> Jerome
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For 
> additional commands, e-mail: dev-help@maven.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional commands, e-mail: dev-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Tomasz Pik <to...@gmail.com>]

On 5/1/07, Hervé BOUTEMY <he...@free.fr> 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 too radical.
> such a LATEST option would be very usefull, not only for plugins but for every
> dependencies, to do regression testing against latest development version of
> everything. It would be like if Gump was integrated into Maven:
> http://gump.apache.org/
>
> I think we would need to differentiate plugin latest from dependencies latest.

This LATEST thing is already in jira: http://jira.codehaus.org/browse/MNG-2431
And I think it would be very useful, both for plugins and for 'normal
dependencies'.

Regards,
Tomek

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Hervé BOUTEMY <he...@free.fr>]

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 usefull, not only for plugins but for every 
dependencies, to do regression testing against latest development version of 
everything. It would be like if Gump was integrated into Maven: 
http://gump.apache.org/

I think we would need to differentiate plugin latest from dependencies latest.

Hervé

>
> Cheers,
>
> Jerome
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Jerome Lacoste <je...@gmail.com>]

On 4/11/07, John Casey <ca...@gmail.com> 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 resolve RELEASE or LATEST meta-versions
> for plugins any more. I'd actually argue that this is bad practice for ANY
> artifact that is to be resolved, including site skins, etc. since it kills
> our ability to deprecate features.

Coming back to this topic.

One of the good thing that we might lose is the fact that less people
would test new releases. Regression would then take more time to get
caught.


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.

Cheers,

Jerome

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Jason van Zyl <ja...@maven.org>]

On 14-Jan-08, at 9:18 AM, Mark Hobson wrote:

> On 03/01/2008, Brett Porter <br...@apache.org> 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
>

I'll look but I assume this is using the notation that actually locks  
down the versions, which was not done previously thereby making the  
POM produced effectively useless for reproducibility.

> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.

-- Robert Pirzig, Zen and the Art of Motorcycle Maintenance 




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Mark Hobson <ma...@gmail.com>]

On 03/01/2008, Brett Porter <br...@apache.org> 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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Brett Porter <br...@apache.org>]

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,  
which causes anything that uses it as a dependency to have a more  
restrictive situation. It really needs the adjustments to the artifact  
system, and the POM, that let you separate the declaration from the  
resolved graph to be useful.

Cheers,
Brett

On 03/01/2008, at 8:10 AM, Matt Ryall wrote:

> On Jan 1, 2008 1:28 AM, Brett Porter <br...@apache.org> 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 inconsistent. It's  
> listed as a
> property for 'release:prepare' at [1], but the example uses
> 'release:perform' [2]. Will the perform always use the release- 
> pom.xml if it
> exists?
>
> Cheers,
> Matt
>
> [1] http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html
> [2]
> http://maven.apache.org/plugins/maven-release-plugin/examples/generate-release-poms.html


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Matt Ryall <ma...@mattryall.net>]

On Jan 1, 2008 1:28 AM, Brett Porter <br...@apache.org> 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 inconsistent. It's listed as a
property for 'release:prepare' at [1], but the example uses
'release:perform' [2]. Will the perform always use the release-pom.xml if it
exists?

Cheers,
Matt

[1] http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html
[2]
http://maven.apache.org/plugins/maven-release-plugin/examples/generate-release-poms.html

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Brett Porter <br...@apache.org>]

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 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
>> for plugins any more. I'd actually argue that this is bad practice  
>> for ANY
>> artifact that is to be resolved, including site skins, etc. since  
>> it kills
>> our ability to deprecate features.
>>
>
> I've read through this complete thread and not seen any proposed  
> solution
> that I like.
>
> How about providing a way to
> (a) dump the current dependencies to an external file, and
> (b) for any build, optionally specify an external "dependency  
> versions" file
> to use when resolving dependencies.
>
> So, the POM still defines "logical" dependencies, eg "version 2.1 or
> greater".
>
> However when a release is about to be made, the release manager:
>
> (1) runs a goal to generate the explicit dependencies file". This file
> contains a list of all the
> dependencies, and the EXACT version that is currently resolved, eg  
> not "2.1
> or greater", but "2.2-beta-1" for example.
>
> (2) checks this explicit dependencies file in to the VCS
>
> (3) builds the release candidate using the explicit dependencies  
> file. Maven
> dependency resolution then *always* uses the dependencies in the  
> input file,
> rather than its usual "best fit" algorithm.
>
> This seems to allow the POM to still remain abstract about  
> dependencies (not
> being locked down to a particular version) while allowing repeatable  
> builds.
> Building without using the checked-in dependencies file does normal
> 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 for
> websites.
>
> Regards,
>
> Simon
> -- 
> View this message in context: http://www.nabble.com/Remove-auto-resolution-of-plugin-versions-from-Maven-2.1-tp9943861s177p14557013.html
> Sent from the Maven Developers mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Simon Kitching <sk...@apache.org>]

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 resolve RELEASE or LATEST meta-versions
> for plugins any more. I'd actually argue that this is bad practice for ANY
> artifact that is to be resolved, including site skins, etc. since it kills
> our ability to deprecate features.
> 

I've read through this complete thread and not seen any proposed solution
that I like.

How about providing a way to 
(a) dump the current dependencies to an external file, and
(b) for any build, optionally specify an external "dependency versions" file
to use when resolving dependencies.

So, the POM still defines "logical" dependencies, eg "version 2.1 or
greater".

However when a release is about to be made, the release manager:

(1) runs a goal to generate the explicit dependencies file". This file
contains a list of all the
dependencies, and the EXACT version that is currently resolved, eg not "2.1
or greater", but "2.2-beta-1" for example.

(2) checks this explicit dependencies file in to the VCS

(3) builds the release candidate using the explicit dependencies file. Maven
dependency resolution then *always* uses the dependencies in the input file,
rather than its usual "best fit" algorithm.

This seems to allow the POM to still remain abstract about dependencies (not
being locked down to a particular version) while allowing repeatable builds.
Building without using the checked-in dependencies file does normal
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 for
websites.

Regards,

Simon
-- 
View this message in context: http://www.nabble.com/Remove-auto-resolution-of-plugin-versions-from-Maven-2.1-tp9943861s177p14557013.html
Sent from the Maven Developers mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org