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]
