please move development discussions to maven-dev, there's already a
thread about it there.
On 4/11/07, Tom Huybrechts <[EMAIL PROTECTED]> wrote:
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]
--
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]
