This has been an interesting discussion to read. I've been thinking about an issue I'm seeing within our development group with versioning of parent POMs. All of our projects reference the same root parent, which has been evolving. Every time any project needs to release, we have to release the root POM, but most projects don't know this is happening, so they become stuck on a previous snapshot release that will no longer get updated.
I've been wondering if it's overly risky to add an enhancement that would allow auto-resolving of dependencies (including parent). The way it would work would be to specify some auto-resolve keyword as the value of the <version> tag. This would use the latest snapshot as the version for each build until it was time to release. At release time, the project owner could fill in the latest release version for each of these and verify that everything works correctly, then release (then switch back to auto-resolve if desired). This could work for the plugins as well. It allows the project owner to decide which plugins/dependencies to lock into a specific version, and which ones to "just use the latest," along with the risks that go with it. I definitely think at release time the POM should be changed to reflect the exact version of everything that release was built with. Thoughts? Are the risks for this sort of thing larger than the benefit it's trying to create? ..David.. -----Original Message----- From: Thierry Lach [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 3:14 AM To: Maven Users List Subject: Re: [IMPORTANT] Maven 2 Plugin Auto-Versioning Considered Dangerous That makes a lot of sense. On 4/12/07, Peter Nilsson <[EMAIL PROTECTED]> wrote: > > The auto-resolver is a pain when using Maven in a corporate > environment when there is a strong requirement to be able to reproduce > a build. As mentioned by others one of the problems is to know which > plugins are used and thus need to have their version locked down. > > I would prefer a property (command line or in pom) that disabled the > auto-resolver and made a build fail if not all versions were explicit. > Then you could choose to use auto-resolver or not, depending on your > priorities on ease of use versus reproducibility. > > Peter > > -----Original Message----- > From: John Casey [mailto:[EMAIL PROTECTED] > Sent: den 11 april 2007 18:19 > To: Maven Users List > Subject: [IMPORTANT] Maven 2 Plugin Auto-Versioning Considered > Dangerous > > Hi everyone, > > I wanted to send out a quick email to let everyone know about some > discussion that's been taking place on the developers' list regarding > plugin versions. In trying to release the 2.2-beta-1 version of the > assembly plugin, it became apparent that this version fixes some bugs > in the 2.1version that don't necessarily look like bugs. All > discussion about what is or is not a bug aside, the discussion raises > an interesting point: if you do not specify a version for the plugins > in your POMs, a situation can arise where Maven will seamlessly > resolve an incompatible plugin version and try to use it. > > Here's an example: > > Say I create a project that uses the assembly plugin, version 2.1. My > assembly descriptor takes advantage of a bug in this version where the > explicit inclusion of a .tar.gz dependency does not have its own > transitive dependencies included, unless they too are explicitly > included. This is incorrect, because there is no ArtifactHandler that > specifies that the .tar.gz file contains its own dependencies (so, > therefore, should not have its transitive dependencies resolved, much > less factored into inclusion/exclusion)...also, from a semantics point > of view, Maven's other dependency usages indicate that specifying a > dependency implies that you're specifying that dependency's transitive > dependencies...the whole sub-graph should be handled, in other words. > > Having created this project with its assembly descriptor, but WITHOUT > A VERSION IN THE ASSEMBLY PLUGIN DECLARATION, I commit my project. > Now, some time later, after the next version of the assembly plugin > fixes this bug, a user comes along. He installs Maven, checks out my > project, and tries to build. Without a single line of code changing in > my project, the build fails, because his Maven instance resolved the > plugin to the newer version. > I cannot replicate his failed build, because my assembly-plugin > version had not been updated (I didn't use -U during the build). > > > You can say that the next version should make an effort to support > users exploiting bugs like this, and you can say that plugins need to > deprecate and gradually move away from behavior that has turned out to > be bad design, counter-intuitive, etc. To this extent, you could argue > that the next release that "fixed" the bug above should have made an > allowance for this scenario. > > However, consider what happens if the plugin has been released several > times...say that the newest version is actually 3.1 now. In this > scenario, it's entirely reasonable to think that the developers have > provided a long migration period - along with deprecation warnings - > that spanned multiple versions, and then finally dropped the support > for this broken configuration. However, Maven has no idea of any of > this, and the aforementioned setup will break. > > All of this can be avoided by simply being careful about evaluating, > then migrating, to new plugin versions in a very deliberate fashion. > If you take a look at the world of systems administration, you see > this sort of thing everywhere. People take enough time to pour over > release notes and determine whether the new version is likely to wreck > the existing setup. The same should go for building a reproducible > build infrastructure. > > I'm going to start a discussion on the developers' for getting rid of > the plugin-version auto-resolver in Maven 2.1 immediately, to start > pushing the tools down this path. However, it will make everyone's > lives easier to start the process now. Please, take a moment and put > the plugin versions into your POMs. > > Thanks, > > 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]
