RE: [m2] Repeatable build and plugin version resolution
This question has also arrisen recently where I work. I suggested putting the local repository of the build machine under version control, so that it can be rolled back to repeat any released build that we create. Hell, we'll probably stick a copy of the jdk, ant, maven, the os, everything we can think of in there too, just to be really sure. I realize that the release management tool can be used to check that no snapshot dependencies are included in a build and to resolve everything to a fixed version number. But there is another problem.. What about poms that use versioning syntax to specify that they can use versions = a certain version ((e.g. [1.5,) for versions = 1.5)? My transitive dependencies may include such a pom without me really being aware of it. Then someone uploads version 2, which breaks my build, but I wasn't using snapshots. Do any solutions for this already exist? is it in the pipeline for the release management stuff? Rupert Smith.
Re: [m2] Repeatable build and plugin version resolution
On 17/01/07, Rupert Smith [EMAIL PROTECTED] wrote: What about poms that use versioning syntax to specify that they can use versions = a certain version ((e.g. [1.5,) for versions = 1.5)? My transitive dependencies may include such a pom without me really being aware of it. Then someone uploads version 2, which breaks my build, but I wasn't using snapshots. Do any solutions for this already exist? is it in the pipeline for the release management stuff? This is currently being discussed, see: http://www.nabble.com/-m2--Generating-release-POMs-tf2944894s177.html Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Repeatable build and plugin version resolution
+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]
RE: [m2] Repeatable build and plugin version resolution
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]
Re: [m2] Repeatable build and plugin version resolution
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]
Re: [m2] Repeatable build and plugin version resolution
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]
[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
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]
