I thought release POMs were meant to resolve the issue of reproducible builds?
Theoretically, when generateReleasePoms=true, release:perform will write an auxiliary POM with resolved versions for all plugins, dependencies, etc. that Maven uses in preference to the normal transformed POM. I say theoretically since it's a documented feature [1] without an implementation [2] ;) I started work on reimplementing this a while back and hopefully will have some more time to finish it off soon. Would this resolve this problem if it became default behaviour? Mark [1] http://maven.apache.org/plugins/maven-release-plugin/examples/generate-release-poms.html [2] http://jira.codehaus.org/browse/MRELEASE-177 On 12/04/07, Franz Allan Valencia See <[EMAIL PROTECTED]> wrote:
I Agree. Minimum configuration should be enough for the common use cases. But if your build fails with the minimum configuration, then that's the time you add in other configurations. IMHO, it's just like the dependency mechanism. A typical user would only have to specify the artifacts he / she is directly using and his build will work most of the time. But if the resolution the user gets fails his / her build, then the user would have to go with the 'best' practice which is to specify all artifacts that his / her project needs. 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]
