Re: Remove auto-resolution of plugin versions from Maven 2.1
On 03/01/2008, Brett Porter [EMAIL PROTECTED] wrote: I said intended, because from memory I wasn't sure if it was still commented out :) I implemented release POMs in maven-release-plugin 2.0-beta-6, see: http://jira.codehaus.org/browse/MRELEASE-177 Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
On 14-Jan-08, at 9:18 AM, Mark Hobson wrote: On 03/01/2008, Brett Porter [EMAIL PROTECTED] wrote: I said intended, because from memory I wasn't sure if it was still commented out :) I implemented release POMs in maven-release-plugin 2.0-beta-6, see: http://jira.codehaus.org/browse/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
On Jan 1, 2008 1:28 AM, Brett Porter [EMAIL PROTECTED] wrote: FWIW, This is precisely the functionality that the generateReleasePoms flag of the release plugin was intended to provide. Intended to provide? Does it actually provide it? The documentation for this flag seems a bit 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
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 [EMAIL PROTECTED] wrote: FWIW, This is precisely the functionality that the generateReleasePoms flag of the release plugin was intended to provide. Intended to provide? Does it actually provide it? The documentation for this flag seems a bit 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Remove auto-resolution of plugin versions from Maven 2.1
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:[EMAIL PROTECTED] 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 versionWORKING/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
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Remove auto-resolution of plugin versions from Maven 2.1
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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
On 5/1/07, Brian E. Fox [EMAIL PROTECTED] wrote: How on earth would you ever debug the inevitable issues when you suddenly upgrade to all new versions of plugins (and worse dependencies?)? because you don't do it suddenly, you would do it continuously. Jerome - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
On 5/1/07, Hervé BOUTEMY [EMAIL PROTECTED] wrote: Le mardi 1 mai 2007, Jerome Lacoste a écrit : Maybe there could be an easy way to let users use the latest ? maybe something like mvn -L ... ( L for latest) that would ignore all specified versions, without requiring a POM change ? Maybe 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] wrote: Le mardi 1 mai 2007, Jerome Lacoste a écrit : Maybe there could be an easy way to let users use the latest ? maybe something like mvn -L ... ( L for latest) that would ignore all specified versions, without requiring a POM change ? Maybe 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Remove auto-resolution of plugin versions from Maven 2.1
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 versionWORKING/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:[EMAIL PROTECTED] Sent: Tuesday, May 01, 2007 1:36 PM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 Le mardi 1 mai 2007, Tomasz Pik a écrit : On 5/1/07, Hervé BOUTEMY [EMAIL PROTECTED] wrote: Le mardi 1 mai 2007, Jerome Lacoste a écrit : Maybe there could be an easy way to let users use the latest ? maybe something like mvn -L ... ( L for latest) that would ignore all specified versions, without requiring a POM change ? Maybe 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
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:[EMAIL PROTECTED] Sent: Tuesday, May 01, 2007 1:36 PM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 Le mardi 1 mai 2007, Tomasz Pik a écrit : On 5/1/07, Hervé BOUTEMY [EMAIL PROTECTED] wrote: Le mardi 1 mai 2007, Jerome Lacoste a écrit : Maybe there could be an easy way to let users use the latest ? maybe something like mvn -L ... ( L for latest) that would ignore all specified versions, without requiring a POM change ? Maybe 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
On 4/11/07, John Casey [EMAIL PROTECTED] wrote: Hi everyone, I'd like to make sure we're all on the same page with the plugin auto-version resolution stuff that we've been discussing lately (on the assembly-plugin vote thread, for one thing). I think it's clear that we cannot continue to allow 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Remove auto-resolution of plugin versions from Maven 2.1
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Remove auto-resolution of plugin versions from Maven 2.1
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
Wendy Smoak-3 wrote: On 4/21/07, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: Well, having the documentation not reflecting the released plugins but SNAPSHOTs is not helpful to any user. We're discussing this now in a different thread. Please add your comments there if you have a 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
Wayne Fay wrote: On 4/21/07, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: So if I say qualityBETA/quality then no alpha bundle (a bundle containing alpha software) will be selected. Who exactly decides what the quality is for a given release? Outside of a handful (literally) of major 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 qualityBETA/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
On 22 Apr 07, at 11:09 PM 22 Apr 07, Wayne Fay wrote: On 4/21/07, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: So if I say qualityBETA/quality then no alpha bundle (a bundle containing alpha software) will be selected. Who exactly decides what the quality is for a given release? Dead 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Remove auto-resolution of plugin versions from Maven 2.1
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Remove auto-resolution of plugin versions from Maven 2.1
Hi Brian, Brian E. Fox wrote on Monday, April 23, 2007 2:42 PM: Everyone keeps referring to bundles that are known to work together. Come someone produce an example of plugins that are incompatible with each other? Annoying: http://jira.codehaus.org/browse/MOJO-641 I haven't seen this and I'm not even sure it's possible given that plugins can't communicate or even know about each other. XDoclet plugin depends on Antrun plugin 1.0. And the dep is declared as *jar* dependency (relying on the fact, that M2 cannot distinguish it). This is the real culprit. 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. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
On 23 Apr 07, at 8:57 AM 23 Apr 07, Jörg Schaible wrote: Hi Brian, Brian E. Fox wrote on Monday, April 23, 2007 2:42 PM: Everyone keeps referring to bundles that are known to work together. Come someone produce an example of plugins that are incompatible with each other? Annoying: http://jira.codehaus.org/browse/MOJO-641 I haven't seen this and I'm not even sure it's possible given that plugins can't communicate or even know about each other. XDoclet plugin depends on Antrun plugin 1.0. And the dep is declared as *jar* dependency (relying on the fact, that M2 cannot distinguish it). This is the real culprit. The base ant tools have now been componentized so that's what should be reused, not another plugin. One plugin extending another is just total anti-pattern in Maven. 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. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Remove auto-resolution of plugin versions from Maven 2.1
I haven't seen this and I'm not even sure it's possible given that plugins can't communicate or even know about each other. XDoclet plugin depends on Antrun plugin 1.0. And the dep is declared as *jar* dependency (relying on the fact, that M2 cannot distinguish it). This is the real culprit. I see, isn't that not recommended? (and now we see why) The dependency stuff should be factored out into a shared component. Tough to do I'm sure if you aren't in control of both plugins. Either way, I don't see a single instance of this requiring a solution for all plugins to be compatible. --Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Remove auto-resolution of plugin versions from Maven 2.1
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Remove auto-resolution of plugin versions from Maven 2.1
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
Wayne Fay wrote: On 4/21/07, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: So if I say qualityBETA/quality then no alpha bundle (a bundle containing alpha software) will be selected. Who exactly decides what the quality is for a given release? Outside of a handful (literally) of major 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 qualityBETA/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
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:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 2:42 PM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 Here's how I deal 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
On 4/21/07, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: So if I say qualityBETA/quality then no alpha bundle (a bundle containing alpha software) will be selected. Who exactly decides what the quality is for a given release? Outside of a handful (literally) of major apps/projects (Linux 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 qualityBETA/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
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 qualityBETA/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
On 4/21/07, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: Well, having the documentation not reflecting the released plugins but SNAPSHOTs is not helpful to any user. We're discussing this now in a different thread. Please add your comments there if you have a preference. http://www.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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Remove auto-resolution of plugin versions from Maven 2.1
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:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 5:24 PM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 I'm interested to know which snapshots bit you guys so hard? Was it a [set of] internal snapshots, or 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 [EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 1:09 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 Right. My point is that regardless of 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
On 4/17/07, Kevin Menard [EMAIL PROTECTED] wrote: support newer releases of external software. At least in the case of Selenium, the authors know that they're released version is broken and their response is to just use SNAPSHOT. That's the sort of scenario I'd like to see avoided if possible. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
On 4/14/07, ArneD [EMAIL PROTECTED] wrote: 2. Many users don't want to make a distinction between Maven itself and the Maven core plugins (compile, jar, ...). This also not true in my experience. Core plugins are not distributed with Maven because we have consciously decoupled the 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
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 [EMAIL PROTECTED] 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:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 10:10 AM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 Same here. -Original Message- From: Stephane Nicoll [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 9:02 AM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 Won't work every time. We have a corporate pom, it's pretty much stable and it won't change often. All our projects inherit from that one, it will be a pain to update everything every time we would want to upgrade some plug-ins. Stéphane On 4/12/07, Hayes, Peter [EMAIL PROTECTED] wrote: I'd like to give my 2 cents on this issue. Would it be possible to maintain a super POM on repo1 that contains a vetted set of plugin versions and then version that POM appropriately based on new releases of core plugins? Then it would simply be an inclusion of a specific parent version in a project POM that would control which plugins to take. I think this is what people probably do internally but if it is maintained on repo1, it would save a lot of work for a lot of people. Peter -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 11, 2007 10:40 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 If I need a specific version (usual to workaround a known issue) then I specify it in the the pom. Otherwise I want the latest. This is the current problem, where builds are done with undetermined versions. (ie the version for dev a might not match dev b) For snapshot builds if I will use specified, then latest. For a released build, I want the pom to be transformed and fully locked down so that the build is reproducible. And I don't want to do that manually. I would expect that my snapshot builds to be exactly the same as the eventual release build for that version. The last thing I need is release to decide for me which versions to use. I do want to do it manually, because I want to try out each new plugin before I bless it and allow it into the build process for the rest of the team. I've had too many occurrences where a plugin change breaks my build (I'm ok with that, it's necessary for forward progress). By manually vetting a plugin, it gives me a chance to make any adjustments needed. It's no different than how we upgrade Maven itself: I have used enforcer to lock my build to 2.0.5 until I can get all the depMgt straightened out and then I will move everyone forward. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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
Re: Remove auto-resolution of plugin versions from Maven 2.1
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
Re: Remove auto-resolution of plugin versions from Maven 2.1
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 [EMAIL PROTECTED] 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:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 10:10 AM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 Same here. -Original Message- From: Stephane Nicoll [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 9:02 AM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 Won't work every time. We have a corporate pom, it's pretty much stable and it won't change often. All our projects inherit from that one, it will be a pain to update everything every time we would want to upgrade some plug-ins. Stéphane On 4/12/07, Hayes, Peter [EMAIL PROTECTED] wrote: I'd like to give my 2 cents on this issue. Would it be possible to maintain a super POM on repo1 that contains a vetted set of plugin versions and then version that POM appropriately based on new releases of core plugins? Then it would simply be an inclusion of a specific parent version in a project POM that would control which plugins to take. I think this is what people probably do internally but if it is maintained on repo1, it would save a lot of work for a lot of people. Peter -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 11, 2007 10:40 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 If I need a specific version (usual to workaround a known issue) then I specify it in the the pom. Otherwise I want the latest. This is the current problem, where builds are done with undetermined versions. (ie the version for dev a might not match dev b) For snapshot builds if I will use specified, then latest. For a released build, I want the pom to be transformed and fully locked down so that the build is reproducible. And I don't want to do that manually. I would expect that my snapshot builds to be exactly the same as the eventual release build for that version. The last thing I need is release to decide for me which versions to use. I do want to do it manually, because I want to try out each new plugin before I bless it and allow it into the build process for the rest of the team. I've had too many occurrences where a plugin change breaks my build (I'm ok with that, it's necessary for forward progress). By manually vetting a plugin, it gives me a chance to make any adjustments needed. It's no different than how we upgrade Maven itself: I have used enforcer to lock my build to 2.0.5 until I can get all the depMgt straightened out and then I will move everyone forward. --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message
Re: Remove auto-resolution of plugin versions from Maven 2.1
On 4/13/07, ArneD [EMAIL PROTECTED] wrote: To adress these issues, may I suggest the following: - Build Maven distributions that include a super POM that declares the latest stable(!) version of all core Maven plugins (i.e. the plugins hosted on maven.apache.org). That won't work. You 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
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.
Re: Remove auto-resolution of plugin versions from Maven 2.1
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: I think every maven release should use a defined set of plugin versions. That would be reproducible and close to what it's happening now. Making the user list all plugins it's gonna be killer for newbies. On 4/11/07, John Casey [EMAIL PROTECTED] wrote: Actually, the unwittingly try and build it with 2.1 scenario is a case where it would be nice to have a prereq on maven 2.1 in the POM. I don't think that 2.0.x supports that sort of thing in the prerequisites section, but I imagine the 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 [EMAIL PROTECTED] wrote: I think it's more complicated than just removing that. Firstly, large numbers of command line plugins will stop working. Secondly, we need to provide a solution for implied plugins (we can set the version in the lifecycle and then let the user 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
Re: Remove auto-resolution of plugin versions from Maven 2.1
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Remove auto-resolution of plugin versions from Maven 2.1
I'd like to give my 2 cents on this issue. Would it be possible to maintain a super POM on repo1 that contains a vetted set of plugin versions and then version that POM appropriately based on new releases of core plugins? Then it would simply be an inclusion of a specific parent version in a project POM that would control which plugins to take. I think this is what people probably do internally but if it is maintained on repo1, it would save a lot of work for a lot of people. Peter -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 11, 2007 10:40 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 If I need a specific version (usual to workaround a known issue) then I specify it in the the pom. Otherwise I want the latest. This is the current problem, where builds are done with undetermined versions. (ie the version for dev a might not match dev b) For snapshot builds if I will use specified, then latest. For a released build, I want the pom to be transformed and fully locked down so that the build is reproducible. And I don't want to do that manually. I would expect that my snapshot builds to be exactly the same as the eventual release build for that version. The last thing I need is release to decide for me which versions to use. I do want to do it manually, because I want to try out each new plugin before I bless it and allow it into the build process for the rest of the team. I've had too many occurrences where a plugin change breaks my build (I'm ok with that, it's necessary for forward progress). By manually vetting a plugin, it gives me a chance to make any adjustments needed. It's no different than how we upgrade Maven itself: I have used enforcer to lock my build to 2.0.5 until I can get all the depMgt straightened out and then I will move everyone forward. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
Won't work every time. We have a corporate pom, it's pretty much stable and it won't change often. All our projects inherit from that one, it will be a pain to update everything every time we would want to upgrade some plug-ins. Stéphane On 4/12/07, Hayes, Peter [EMAIL PROTECTED] wrote: I'd like to give my 2 cents on this issue. Would it be possible to maintain a super POM on repo1 that contains a vetted set of plugin versions and then version that POM appropriately based on new releases of core plugins? Then it would simply be an inclusion of a specific parent version in a project POM that would control which plugins to take. I think this is what people probably do internally but if it is maintained on repo1, it would save a lot of work for a lot of people. Peter -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 11, 2007 10:40 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 If I need a specific version (usual to workaround a known issue) then I specify it in the the pom. Otherwise I want the latest. This is the current problem, where builds are done with undetermined versions. (ie the version for dev a might not match dev b) For snapshot builds if I will use specified, then latest. For a released build, I want the pom to be transformed and fully locked down so that the build is reproducible. And I don't want to do that manually. I would expect that my snapshot builds to be exactly the same as the eventual release build for that version. The last thing I need is release to decide for me which versions to use. I do want to do it manually, because I want to try out each new plugin before I bless it and allow it into the build process for the rest of the team. I've had too many occurrences where a plugin change breaks my build (I'm ok with that, it's necessary for forward progress). By manually vetting a plugin, it gives me a chance to make any adjustments needed. It's no different than how we upgrade Maven itself: I have used enforcer to lock my build to 2.0.5 until I can get all the depMgt straightened out and then I will move everyone forward. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Remove auto-resolution of plugin versions from Maven 2.1
Same here. -Original Message- From: Stephane Nicoll [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 9:02 AM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 Won't work every time. We have a corporate pom, it's pretty much stable and it won't change often. All our projects inherit from that one, it will be a pain to update everything every time we would want to upgrade some plug-ins. Stéphane On 4/12/07, Hayes, Peter [EMAIL PROTECTED] wrote: I'd like to give my 2 cents on this issue. Would it be possible to maintain a super POM on repo1 that contains a vetted set of plugin versions and then version that POM appropriately based on new releases of core plugins? Then it would simply be an inclusion of a specific parent version in a project POM that would control which plugins to take. I think this is what people probably do internally but if it is maintained on repo1, it would save a lot of work for a lot of people. Peter -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 11, 2007 10:40 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 If I need a specific version (usual to workaround a known issue) then I specify it in the the pom. Otherwise I want the latest. This is the current problem, where builds are done with undetermined versions. (ie the version for dev a might not match dev b) For snapshot builds if I will use specified, then latest. For a released build, I want the pom to be transformed and fully locked down so that the build is reproducible. And I don't want to do that manually. I would expect that my snapshot builds to be exactly the same as the eventual release build for that version. The last thing I need is release to decide for me which versions to use. I do want to do it manually, because I want to try out each new plugin before I bless it and allow it into the build process for the rest of the team. I've had too many occurrences where a plugin change breaks my build (I'm ok with that, it's necessary for forward progress). By manually vetting a plugin, it gives me a chance to make any adjustments needed. It's no different than how we upgrade Maven itself: I have used enforcer to lock my build to 2.0.5 until I can get all the depMgt straightened out and then I will move everyone forward. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: I'd like to give my 2 cents on this issue. Would it be possible to maintain a super POM on repo1 that contains a vetted set of plugin versions and then version that POM appropriately based on new releases of core plugins? Then it would simply be an inclusion of a specific parent version in a project POM that would control which plugins to take. I think this is what people probably do internally but if it is maintained on repo1, it would save a lot of work for a lot of people. Peter -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 11, 2007 10:40 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 If I need a specific version (usual to workaround a known issue) then I specify it in the the pom. Otherwise I want the latest. This is the current problem, where builds are done with undetermined versions. (ie the version for dev a might not match dev b) For snapshot builds if I will use specified, then latest. For a released build, I want the pom to be transformed and fully locked down so that the build is reproducible. And I don't want to do that manually. I would expect that my snapshot builds to be exactly the same as the eventual release build for that version. The last thing I need is release to decide for me which versions to use. I do want to do it manually, because I want to try out each new plugin before I bless it and allow it into the build process
Re: Remove auto-resolution of plugin versions from Maven 2.1
people probably do internally but if it is maintained on repo1, it would save a lot of work for a lot of people. Peter -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 11, 2007 10:40 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 If I need a specific version (usual to workaround a known issue) then I specify it in the the pom. Otherwise I want the latest. This is the current problem, where builds are done with undetermined versions. (ie the version for dev a might not match dev b) For snapshot builds if I will use specified, then latest. For a released build, I want the pom to be transformed and fully locked down so that the build is reproducible. And I don't want to do that manually. I would expect that my snapshot builds to be exactly the same as the eventual release build for that version. The last thing I need is release to decide for me which versions to use. I do want to do it manually, because I want to try out each new plugin before I bless it and allow it into the build process for the rest of the team. I've had too many occurrences where a plugin change breaks my build (I'm ok with that, it's necessary for forward progress). By manually vetting a plugin, it gives me a chance to make any adjustments needed. It's no different than how we upgrade Maven itself: I have used enforcer to lock my build to 2.0.5 until I can get all the depMgt straightened out and then I will move everyone forward. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 11:00 AM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 One thing I wanted to add: To me, it's critical to view your 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Remove auto-resolution of plugin versions from Maven 2.1
Right I get that. That would be pretty annoying. Maybe instead of a parent POM, an import facility could be used that can grab the same centralized POM (Multiple-inheritance almost :-). To John's comment, I don't see this being a big offline challenge as this centralized POM would be a released version that could safely be cached in a local repository, like any other artifact, i.e. it would follow the snapshot / release methodology. Peter -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 10:10 AM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 Same here. -Original Message- From: Stephane Nicoll [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 9:02 AM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 Won't work every time. We have a corporate pom, it's pretty much stable and it won't change often. All our projects inherit from that one, it will be a pain to update everything every time we would want to upgrade some plug-ins. Stéphane On 4/12/07, Hayes, Peter [EMAIL PROTECTED] wrote: I'd like to give my 2 cents on this issue. Would it be possible to maintain a super POM on repo1 that contains a vetted set of plugin versions and then version that POM appropriately based on new releases of core plugins? Then it would simply be an inclusion of a specific parent version in a project POM that would control which plugins to take. I think this is what people probably do internally but if it is maintained on repo1, it would save a lot of work for a lot of people. Peter -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 11, 2007 10:40 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 If I need a specific version (usual to workaround a known issue) then I specify it in the the pom. Otherwise I want the latest. This is the current problem, where builds are done with undetermined versions. (ie the version for dev a might not match dev b) For snapshot builds if I will use specified, then latest. For a released build, I want the pom to be transformed and fully locked down so that the build is reproducible. And I don't want to do that manually. I would expect that my snapshot builds to be exactly the same as the eventual release build for that version. The last thing I need is release to decide for me which versions to use. I do want to do it manually, because I want to try out each new plugin before I bless it and allow it into the build process for the rest of the team. I've had too many occurrences where a plugin change breaks my build (I'm ok with that, it's necessary for forward progress). By manually vetting a plugin, it gives me a chance to make any adjustments needed. It's no different than how we upgrade Maven itself: I have used enforcer to lock my build to 2.0.5 until I can get all the depMgt straightened out and then I will move everyone forward. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
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 [EMAIL PROTECTED] 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:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 10:10 AM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 Same here. -Original Message- From: Stephane Nicoll [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 9:02 AM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 Won't work every time. We have a corporate pom, it's pretty much stable and it won't change often. All our projects inherit from that one, it will be a pain to update everything every time we would want to upgrade some plug-ins. Stéphane On 4/12/07, Hayes, Peter [EMAIL PROTECTED] wrote: I'd like to give my 2 cents on this issue. Would it be possible to maintain a super POM on repo1 that contains a vetted set of plugin versions and then version that POM appropriately based on new releases of core plugins? Then it would simply be an inclusion of a specific parent version in a project POM that would control which plugins to take. I think this is what people probably do internally but if it is maintained on repo1, it would save a lot of work for a lot of people. Peter -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 11, 2007 10:40 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 If I need a specific version (usual to workaround a known issue) then I specify it in the the pom. Otherwise I want the latest. This is the current problem, where builds are done with undetermined versions. (ie the version for dev a might not match dev b) For snapshot builds if I will use specified, then latest. For a released build, I want the pom to be transformed and fully locked down so that the build is reproducible. And I don't want to do that manually. I would expect that my snapshot builds to be exactly the same as the eventual release build for that version. The last thing I need is release to decide for me which versions to use. I do want to do it manually, because I want to try out each new plugin before I bless it and allow it into the build process for the rest of the team. I've had too many occurrences where a plugin change breaks my build (I'm ok with that, it's necessary for forward progress). By manually vetting a plugin, it gives me a chance to make any adjustments needed. It's no different than how we upgrade Maven itself: I have used enforcer to lock my build to 2.0.5 until I can get all the depMgt straightened out and then I will move everyone forward. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 11:08 AM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 John, I think you've hit the nail on the head here. If you look at it this way, your plugins used are 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:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 11:00 AM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 One thing I wanted to add: To me, it's critical to view your 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 12:50 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 A bit of a departure from the discussion, but still related . . . It may be worthwhile to rethink the whole SNAPSHOT system, too, 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:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 11:08 AM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 John, I think you've hit the nail on the head here. If you look at it this way, your plugins used are 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:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 11:00 AM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 One thing I wanted to add: To me, it's critical to view your 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 12:50 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 A bit of a departure from the discussion, but still related . . . It may be worthwhile to rethink the whole SNAPSHOT system, too, 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:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 11:08 AM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 John, I think you've hit the nail on the head here. If you look at it this way, your plugins used are 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:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 11:00 AM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 One thing I wanted to add: To me, it's critical to view your 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: Remove auto-resolution of plugin versions from Maven 2.1
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: I'd like to give my 2 cents on this issue. Would it be possible to maintain a super POM on repo1 that contains a vetted set of plugin versions and then version that POM appropriately based on new releases of core plugins? Then it would simply be an inclusion of a specific parent version in a project POM that would control which plugins to take. I think this is what people probably do internally but if it is maintained on repo1, it would save a lot of work for a lot of people. Peter -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 11, 2007 10:40 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 If I need a specific version (usual to workaround a known issue) then I specify it in the the pom
Re: Remove auto-resolution of plugin versions from Maven 2.1
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
people probably do internally but if it is maintained on repo1, it would save a lot of work for a lot of people. Peter -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 11, 2007 10:40 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 If I need a specific version (usual to workaround a known issue) then I specify it in the the pom. Otherwise I want the latest. This is the current problem, where builds are done with undetermined versions. (ie the version for dev a might not match dev b) For snapshot builds if I will use specified, then latest. For a released build, I want the pom to be transformed and fully locked down so that the build is reproducible. And I don't want to do that manually. I would expect that my snapshot builds to be exactly the same as the eventual release build for that version. The last thing I need is release to decide for me which versions to use. I do want to do it manually, because I want to try out each new plugin before I bless it and allow it into the build process for the rest of the team. I've had too many occurrences where a plugin change breaks my build (I'm ok with that, it's necessary for forward progress). By manually vetting a plugin, it gives me a chance to make any adjustments needed. It's no different than how we upgrade Maven itself: I have used enforcer to lock my build to 2.0.5 until I can get all the depMgt straightened out and then I will move everyone forward. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
Re: Remove auto-resolution of plugin versions from Maven 2.1
cents on this issue. Would it be possible to maintain a super POM on repo1 that contains a vetted set of plugin versions and then version that POM appropriately based on new releases of core plugins? Then it would simply be an inclusion of a specific parent version in a project POM that would control which plugins to take. I think this is what people probably do internally but if it is maintained on repo1, it would save a lot of work for a lot of people. Peter -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 11, 2007 10:40 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 If I need a specific version (usual to workaround a known issue) then I specify it in the the pom. Otherwise I want the latest. This is the current problem, where builds are done with undetermined versions. (ie the version for dev a might not match dev b) For snapshot builds if I will use specified, then latest. For a released build, I want the pom to be transformed and fully locked down so that the build is reproducible. And I don't want to do that manually. I would expect that my snapshot builds to be exactly the same as the eventual release build for that version. The last thing I need is release to decide for me which versions to use. I do want to do it manually, because I want to try out each new plugin before I bless it and allow it into the build process for the rest of the team. I've had too many occurrences where a plugin change breaks my build (I'm ok with that, it's necessary for forward progress). By manually vetting a plugin, it gives me a chance to make any adjustments needed. It's no different than how we upgrade Maven itself: I have used enforcer to lock my build to 2.0.5 until I can get all the depMgt straightened out and then I will move everyone forward. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] wrote: Here's how I deal with instances where I need a snapshot plugin in my corp build: 1. Checkout the code for the snapshot. 2. Build it, changing the version to something like 2.0-[companyname]-svnrev 3. If I have to patch the source at all, I take 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Remove auto-resolution of plugin versions from Maven 2.1
Yes I also agree this would be handy at times. -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 2:53 PM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 Sounds like a great idea for a very useful plugin. I'm sure many of us have followed this same pattern when it comes time to do a release which utilizes snapshot plugins or artifacts. Wayne On 4/12/07, Nigel Magnay [EMAIL PROTECTED] wrote: Here's how I deal with instances where I need a 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Remove auto-resolution of plugin versions from Maven 2.1
I wrote this up here: http://jira.codehaus.org/browse/MNG-2945 -Original Message- From: Nigel Magnay [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 2:42 PM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 Here's how I deal 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 1:09 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 Right. My point is that regardless of 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Remove auto-resolution of plugin versions from Maven 2.1
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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 1:09 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 Right. My point is that regardless of 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
On 4/13/07, Brian E. Fox [EMAIL PROTECTED] wrote: Here's how I deal with instances where I need a snapshot plugin in my corp build: 1. Checkout the code for the snapshot. 2. Build it, changing the version to something like 2.0-[companyname]-svnrev 3. If I have to patch the source at all, I take 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
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 [EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 1:09 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 Right. My point is that regardless of 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Remove auto-resolution of plugin versions from Maven 2.1
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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
On 4/11/07, Brett Porter [EMAIL PROTECTED] wrote: I think it's more complicated than just removing that. Firstly, large numbers of command line plugins will stop working. Secondly, we need to provide a solution for implied plugins (we can set the version in the lifecycle and then let the user 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Remove auto-resolution of plugin versions from Maven 2.1
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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
+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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
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 [EMAIL PROTECTED] wrote: I think it's more complicated than just removing that. Firstly, large numbers of command line plugins will stop working. Secondly, we need to provide a solution for implied plugins (we can set the version in the lifecycle and then let the user 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
I think every maven release should use a defined set of plugin versions. That would be reproducible and close to what it's happening now. Making the user list all plugins it's gonna be killer for newbies. On 4/11/07, John Casey [EMAIL PROTECTED] wrote: Actually, the unwittingly try and build 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 [EMAIL PROTECTED] wrote: I think it's more complicated than just removing that. Firstly, large numbers of command line plugins will stop working. Secondly, we need to provide a solution for implied plugins (we can set the version in the lifecycle and then let the user 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
I have to agree with Carlos, it is a killer for newbies, and it means slow adoption But speaking from my experience, I ended up to specify all plugin versions to reduce ambiguities. -D On 4/11/07, Carlos Sanchez [EMAIL PROTECTED] wrote: I think every maven release should use a defined set of plugin versions. That would be reproducible and close to what it's happening now. Making the user list all plugins it's gonna be killer for newbies. On 4/11/07, John Casey [EMAIL PROTECTED] wrote: Actually, the unwittingly try and build 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 [EMAIL PROTECTED] wrote: I think it's more complicated than just removing that. Firstly, large numbers of command line plugins will stop working. Secondly, we need to provide a solution for implied plugins (we can set the version in the lifecycle and then let the user 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: I think every maven release should use a defined set of plugin versions. That would be reproducible and close to what it's happening now. Making the user list all plugins it's gonna be killer for newbies. On 4/11/07, John Casey [EMAIL PROTECTED] wrote: Actually, the unwittingly try and build it with 2.1 scenario is a case where it would be nice to have a prereq on maven 2.1 in the POM. I don't think that 2.0.x supports that sort of thing in the prerequisites section, but I imagine the 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 [EMAIL PROTECTED] wrote: I think it's more complicated than just removing that. Firstly, large numbers of command line plugins will stop working. Secondly, we need to provide a solution for implied plugins (we can set the version in the lifecycle and then let the user 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
On 4/11/07, John Casey [EMAIL PROTECTED] wrote: Actually, the unwittingly try and build it with 2.1 scenario is a case where it would be nice to have a prereq on maven 2.1 in the POM. I don't think that 2.0.x supports that sort of thing in the prerequisites section, but I imagine the 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
On 4/12/07, Carlos Sanchez [EMAIL PROTECTED] wrote: I think every maven release should use a defined set of plugin versions. That would be reproducible and close to what it's happening now. Making the user list all plugins it's gonna be killer for newbies. If I need a specific version (usual 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
On 4/11/07, Barrie Treloar [EMAIL PROTECTED] wrote: On 4/12/07, Carlos Sanchez [EMAIL PROTECTED] wrote: I think every maven release should use a defined set of plugin versions. That would be reproducible and close to what it's happening now. Making the user list all plugins it's gonna be 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Remove auto-resolution of plugin versions from Maven 2.1
I don't see the connection between javax.* and the plugins? -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 11, 2007 4:10 PM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 Strongly agree with Carlos and Dan. We already have enough troubles on M-U with web proxies and javax.* artifacts not available in Central, we really don't need to add to the troubles by requiring users to specify every single plugin. Wayne On 4/11/07, Dan Tran [EMAIL PROTECTED] wrote: I have to agree with Carlos, it is a killer for newbies, and it means slow adoption But speaking from my experience, I ended up to specify all plugin versions to reduce ambiguities. -D On 4/11/07, Carlos Sanchez [EMAIL PROTECTED] wrote: I think every maven release should use a defined set of plugin versions. That would be reproducible and close to what it's happening now. Making the user list all plugins it's gonna be killer for newbies. On 4/11/07, John Casey [EMAIL PROTECTED] wrote: Actually, the unwittingly try and build 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 [EMAIL PROTECTED] wrote: I think it's more complicated than just removing that. Firstly, large numbers of command line plugins will stop working. Secondly, we need to provide a solution for implied plugins (we can set the version in the lifecycle and then let the user 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: [EMAIL PROTECTED] For additional commands, e-mail
RE: Remove auto-resolution of plugin versions from Maven 2.1
If I need a specific version (usual to workaround a known issue) then I specify it in the the pom. Otherwise I want the latest. This is the current problem, where builds are done with undetermined versions. (ie the version for dev a might not match dev b) For snapshot builds if I will use specified, then latest. For a released build, I want the pom to be transformed and fully locked down so that the build is reproducible. And I don't want to do that manually. I would expect that my snapshot builds to be exactly the same as the eventual release build for that version. The last thing I need is release to decide for me which versions to use. I do want to do it manually, because I want to try out each new plugin before I bless it and allow it into the build process for the rest of the team. I've had too many occurrences where a plugin change breaks my build (I'm ok with that, it's necessary for forward progress). By manually vetting a plugin, it gives me a chance to make any adjustments needed. It's no different than how we upgrade Maven itself: I have used enforcer to lock my build to 2.0.5 until I can get all the depMgt straightened out and then I will move everyone forward. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
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 [EMAIL PROTECTED] wrote: I don't see the connection between javax.* and the plugins? -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 11, 2007 4:10 PM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 Strongly agree with Carlos and Dan. We already have enough troubles on M-U with web proxies and javax.* artifacts not available in Central, we really don't need to add to the troubles by requiring users to specify every single plugin. Wayne On 4/11/07, Dan Tran [EMAIL PROTECTED] wrote: I have to agree with Carlos, it is a killer for newbies, and it means slow adoption But speaking from my experience, I ended up to specify all plugin versions to reduce ambiguities. -D On 4/11/07, Carlos Sanchez [EMAIL PROTECTED] wrote: I think every maven release should use a defined set of plugin versions. That would be reproducible and close to what it's happening now. Making the user list all plugins it's gonna be killer for newbies. On 4/11/07, John Casey [EMAIL PROTECTED] wrote: Actually, the unwittingly try and build 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 [EMAIL PROTECTED] wrote: I think it's more complicated than just removing that. Firstly, large numbers of command line plugins will stop working. Secondly, we need to provide a solution for implied plugins (we can set the version in the lifecycle and then let the user 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
Re: Remove auto-resolution of plugin versions from Maven 2.1
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: I think every maven release should use a defined set of plugin versions. That would be reproducible and close to what it's happening now. Making the user list all plugins it's gonna be killer for newbies. On 4/11/07, John Casey [EMAIL PROTECTED] wrote: Actually, the unwittingly try and build it with 2.1 scenario is a case where it would be nice to have a prereq on maven 2.1 in the POM. I don't think that 2.0.x supports that sort of thing in the prerequisites section, but I imagine the 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 [EMAIL PROTECTED] wrote: I think it's more complicated than just removing that. Firstly, large numbers of command line plugins will stop working. Secondly, we need to provide a solution for implied plugins (we can set the version in the lifecycle and then let the user 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've
