maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian E. Fox" <bri...@reply.infinity.nu>
Subject RE: Remove auto-resolution of plugin versions from Maven 2.1
Date Thu, 12 Apr 2007 02:07:40 GMT
I don't see the connection between javax.* and the plugins?

-----Original Message-----
From: Wayne Fay [mailto:waynefay@gmail.com] 
Sent: Wednesday, April 11, 2007 4:10 PM
To: Maven Developers List
Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1

Strongly agree with Carlos and Dan. We already have enough troubles on
M-U with web proxies and javax.* artifacts not available in Central,
we really don't need to add to the troubles by requiring users to
specify every single plugin.

Wayne

On 4/11/07, Dan Tran <dantran@gmail.com> wrote:
> I have to agree with Carlos, it is a killer for newbies, and it means
slow
> adoption
>
> But speaking from  my experience, I ended up to specify all plugin
versions
> to reduce ambiguities.
>
> -D
>
>
> On 4/11/07, Carlos Sanchez <carlos@apache.org> wrote:
> >
> > 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 <casey.john.d@gmail.com> 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 <brett@apache.org> 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: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> >                             -- The Princess Bride
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message