Two more ideas: - Versioned lifecycles. Let a version of a lifecycle map to versions of each of its plugins. Allow users to override these by specifying explicit versions for the plugins. If you don't specify a version for the packaging, you get the old behaviour.
- Have the maven-release-plugin add versions for all plugins, so you would at least have reproduciblity for releases. There must be a JIRA for this already, but I couldn't find it. Tom On 4/11/07, John Casey <[EMAIL PROTECTED]> wrote:
I think that sort of plugin would be a great idea. For the plugins in the standard packaging lifecycles (to which you're referring, I believe), I still think that Maven should force you to supply a version for each one. It might make sense to have a version-set dependency or artifact that you can use to specify them as a group, so you have a sort of standardized toolchain for your build. This is possible via parent POM and pluginManagement today, but it is sort of orthogonal to normal inheritance in some ways, too... -john On 4/11/07, Tom Huybrechts <[EMAIL PROTECTED]> wrote: > > Don't forget you use a lot more plugins than you think. Who specifies > versions for resources; compiler, surefire, install, deploy, clean, > ... ? > Maybe we need a plugin that can rewrite your POMs to specify versions > for all the plugins that are used ? > > Tom > > On 4/11/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > > I agree, automatic resolution of plugin versions is dangerous and you > > must use versions if you want reproducible builds. it's easy to add > > them to your parent pom in the pluginManagement section > > > > On 4/11/07, John Casey <[EMAIL PROTECTED]> wrote: > > > 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 > > > > > > > > > -- > > 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] > > > > > > --------------------------------------------------------------------- > 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]
