I don't see the connection between javax.* and the plugins? -----Original Message----- From: Wayne Fay [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[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] > > > > > --------------------------------------------------------------------- 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]
