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]
