+1 to all of the above. :) We certainly aim to provide reproducible remote repositories, however there are currently some variables that need to be tightened up.
The release plugin is certainly heading in this direction. - Brett On 1/16/06, Chris Berry <[EMAIL PROTECTED]> wrote: > I agree 100%. The Release Plugin should > 1) Insure that all dependency versions, including those of maven itself, are > captured for repeatability > 2) Insure that no dependencies, including those of maven itself, are > SNAPSHOTs, which, by definition, are not repeatable > > BTW: to truly insure repeatability, one should also create their own maven > remote repo and move versions off the Internet, The Internaet is too flaky > to assume that some version you require will still be available in 6 months. > (I think maven-proxy -- with a backup system -- could help a lot here...) > Cheers, > -- Chris > > On 1/16/06, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > > > > > I'd LOVE an extension to the release plugin or something that would go > > through the build and create a properties file with the version numbers > > for ALL dependencies and updates the poms to use it. Thus, we could > > easily see what versions of stuff is being loaded (important for audits) > > as well as lock down the versions as you release the code. The > > properties file could be checked into source control so the build is > > completely repeatable. > > > > Dan > > > > > > On Monday 16 January 2006 06:27, Scokart Gilles wrote: > > > It's also the approach I had in mind. But, I can not be sure that all > > > the plug-in versions are defined in the pom(s). > > > > > > A solution would be to have a parameter on the command line > > > "--repeatable". With such a flag asking for plugin version number > > > resolved with information coming from the pom(s) only. > > > > > > Does it make sense? Or did I miss something? > > > > > > > > > Gilles > > > > > > > -----Original Message----- > > > > From: Brian E. Fox [mailto:[EMAIL PROTECTED] > > > > Sent: 14 January 2006 19:25 > > > > To: Maven Users List > > > > Subject: RE: [m2] Repeatable build and plugin version resolution > > > > > > > > I think the standard and easiest to manage is to create a parent pom > > > > that your projects inherit from. In this pom, put your plugin and > > > > dependency versions in the pluginMangement and dependencyManagement > > > > section. Then when you don't specify the version in your child pom's > > > > the version from the parent is used. It makes it much easier to > > > > control your build environment, especially having control over the > > > > plugins. > > > > > > > > -----Original Message----- > > > > From: Scokart Gilles [mailto:[EMAIL PROTECTED] > > > > Sent: Saturday, January 14, 2006 12:17 PM > > > > To: Maven Users List > > > > Subject: [m2] Repeatable build and plugin version resolution > > > > > > > > > > > > > > > > How can we guarantee a repeatable build? I mean, when I build a > > > > project, the most recent available versions of the plugins are used. > > > > That means that there is a risk that rebuilding a project after 6 > > > > months provides a different result. > > > > > > > > > > > > > > > > I know that it possible to force the plugins version number in the > > > > pom.xml. > > > > But how can we guarantee we don't miss one when writing the pom? > > > > > > > > > > > > > > > > Is there other approach (Maybe linked with the plugin registry)? > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > SCOKART Gilles > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > 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] > > > > -- > > J. Daniel Kulp > > Principal Engineer > > IONA > > P: 781-902-8727 C: 508-380-7194 > > [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]
