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]
