Re: Lightweight maven-releases, or an alternative to the maven-release-plugin
- when speaking about SNAPSHOTs we should distinguish between dependencies and what we produce. With a build we produce an artifact which is either a SNAPSHOT or release according to the version in the pom.xml. A dependency resolves either to a SNAPSHOT or a released version of another library. The dependency might be internal (modules built within the same reactor) or external. - an external dependency should never be a SNAPSHOT (it makes life easier anyway ;-), should only be allowed temporarily. - all modules in our multi module project always have the same version (e.g. 0.1.0-SNAPSHOT) and dependencies are defined with ${project.version} When produce artifacts we deploy them to our target environment (e.g. war-file to app-server, db scripts to database...) and make some tests. All this stuff is done during the night in an automated way. We have other stages where we have to deploy a build which has passed this first tests but normally, this happens some days later. That's why a SNAPSHOT is not enough as it's hard to track down which SNAPSHOT we can deliver. In other words: It's important what we produce and less important what's in it (e.g. SNAPSHOT or not) as we test if it works or not. Don't get me wrong: we avoid having SNAPSHOT deps and when it goes to production we don't have SNAPSHOT libs anymore! But during development this is ok. And that's what we do all the time: during the day we do continuous builds (mvn clean install) in the night we create an ad-hoc release with mvn clean install -Dversion.override=x.y-n which is virtually changing the ${project.version} in all our pom.xml but not changing anything in our version control. And if something fails we don't repeat we start a new one. By the way: The version.override feature has options to let a build fail or issue a warning when it detects SNAPSHOT deps. This is not documented but it's there. Cheers, Rotsch 2013/5/2 Mirko Friedenhagen mfriedenha...@gmail.com Hello there, I. find prepare and perform quite heavyweight my self. After prepare did build everything successfully, it throws away everything, just tags the source and starts over again during perform. prepare already checks with scm means, that there are no modifications and in my experience tagging is the most harmless operation in the whole process (well, would I still use CVS that could be different). So running prepare with prepareGoals set to -DperformRelease=true clean deploy does what *I* want. - checks I have everything in SCM - does modify POMs for release. - deploys to staging - only on success of this tags the sources - go back to SNAPSHOT. git and svn (when not doing the strange remoteTagging) are capable of tagging always. Worst thing that might happen: bad stuff in staging for a short time. Regards Mirko -- Sent from my mobile On May 1, 2013 9:15 PM, Robert Scholte rfscho...@apache.org wrote: Graham, well said. Although the pom.xml is the easiest way to discover the version, it is not the best location, since it would require a commit. The solution must be found in a generated file which will be added to the artifact during packaging. Here you could add a timestamp or revision. Robert Op Wed, 01 May 2013 12:44:19 +0200 schreef Graham Leggett minf...@sharp.fm: On 30 Apr 2013, at 11:21 PM, Roger Brechbühl rotscher...@gmail.com wrote: Maybe somebody is interested in how a release could be built in a more lightweight and safe way than with the maven-release-plugin. Especially recommended for nightly releases. It's not yet released, but basically fully working: *mvn clean install -Dversion.override=1.2.3-S-5* https://github.com/rotscher/**emerging/tree/version.** override-with_maven_install-2.**4 https://github.com/rotscher/emerging/tree/version.override-with_maven_install-2.4 Maven has a very clear definition of a release, being an artefact that can traced back to the precise code via a tag, and a build that can be repeated. This is as opposed to a snapshot, which has no well defined origin. You might approach this two ways, you might create nightly snapshots and have them deployed somewhere suitable, using mvn deploy. Alternatively if you want to create proper nightly releases (in the maven sense), you could feed a custom version number into the release plugin to represent your release, but this starts to smell like that's what a snapshot is for. Regards, Graham -- --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Lightweight maven-releases, or an alternative to the maven-release-plugin
Hello, if interested: the topic of lightweight maven releases is discussed in DevOps for Developers, Apress, Chapter 8. Cheers, Michael Hello there, I. find prepare and perform quite heavyweight my self. After prepare did build everything successfully, it throws away everything, just tags the source and starts over again during perform. prepare already checks with scm means, that there are no modifications and in my experience tagging is the most harmless operation in the whole process (well, would I still use CVS that could be different). So running prepare with prepareGoals set to -DperformRelease=true clean deploy does what *I* want. - checks I have everything in SCM - does modify POMs for release. - deploys to staging - only on success of this tags the sources - go back to SNAPSHOT. git and svn (when not doing the strange remoteTagging) are capable of tagging always. Worst thing that might happen: bad stuff in staging for a short time. Regards Mirko -- Sent from my mobile On May 1, 2013 9:15 PM, Robert Scholte rfscho...@apache.org wrote: Graham, well said. Although the pom.xml is the easiest way to discover the version, it is not the best location, since it would require a commit. The solution must be found in a generated file which will be added to the artifact during packaging. Here you could add a timestamp or revision. Robert Op Wed, 01 May 2013 12:44:19 +0200 schreef Graham Leggett minf...@sharp.fm: On 30 Apr 2013, at 11:21 PM, Roger Brechbühl rotscher...@gmail.com wrote: Maybe somebody is interested in how a release could be built in a more lightweight and safe way than with the maven-release-plugin. Especially recommended for nightly releases. It's not yet released, but basically fully working: *mvn clean install -Dversion.override=1.2.3-S-5* https://github.com/rotscher/**emerging/tree/version.** override-with_maven_install-2.**4https://github.com/rotscher/emerging/tree/version.override-with_maven_install-2.4 Maven has a very clear definition of a release, being an artefact that can traced back to the precise code via a tag, and a build that can be repeated. This is as opposed to a snapshot, which has no well defined origin. You might approach this two ways, you might create nightly snapshots and have them deployed somewhere suitable, using mvn deploy. Alternatively if you want to create proper nightly releases (in the maven sense), you could feed a custom version number into the release plugin to represent your release, but this starts to smell like that's what a snapshot is for. Regards, Graham -- --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Lightweight maven-releases, or an alternative to the maven-release-plugin
Hi Nambi 1. Why does the jar need to be part of maven installation? Why not a plugin? The version given on the command line is passed into the model when it's loaded (model.setVersion(version)). And this is done for all modules when the model is read. When having a plugin I would change the version when the module is built. And I guess, it's not possible at that time. And as there is a different install-plugin for the install phase, I'll change that in the lifecycle mapper (which is also part of the maven installation). 2. Can it generate a version based on some strategy? Looks like the version needs to be supplied through CLI parameter. With Release 0.2.0 there are more possibilites to generate a unique version number: when the feature is active but no version is provided then the pom version is taken and a buildnumber is appended. The buildnumber is either taken from jenkins/hudson (env.BUILD_NUMBER) or its an incremented integer stored in a file named .buildnumber Of course, it would be possible to think about different version generation strategies. 3. Some releases need a TAG in SCM while some releases don't require a TAG. Is there a possibility of having this functionality? I guess this would be possible. To me storing the revision number into the manifest files is more important. With this information you can always tag and/or branch from a specific revision. 4. What happens if the release is trying to overwrite an already existing version on the repository? This should be configured in your central maven repo (e.g. Nexus/Archiva) where you configure a repository to not allow releases to be overwritten. 5. What kind of formats are supported? jar, war etc. I don't get this question... Actually all generated artifacts are handled the same way. Cheers, Rotsch 2013/5/1 Sankaran, Nambi nsanka...@ebay.com Hi Rotch This sounds quite interesting and I feel it would be useful to a lot of projects. The release-plugin as it is, is not very flexible. Questions 1. Why does the jar need to be part of maven installation? Why not a plugin? 2. Can it generate a version based on some strategy? Looks like the version needs to be supplied through CLI parameter. 3. Some releases need a TAG in SCM while some releases don't require a TAG. Is there a possibility of having this functionality? 4. What happens if the release is trying to overwrite an already existing version on the repository? 5. What kind of formats are supported? jar, war etc. Thanks nambi -Original Message- From: Roger Brechbühl [mailto:rotscher...@gmail.com] Sent: Tuesday, April 30, 2013 2:22 PM To: users@maven.apache.org Subject: Lightweight maven-releases, or an alternative to the maven-release-plugin Hi all Maybe somebody is interested in how a release could be built in a more lightweight and safe way than with the maven-release-plugin. Especially recommended for nightly releases. It's not yet released, but basically fully working: *mvn clean install -Dversion.override=1.2.3-S-5* https://github.com/rotscher/emerging/tree/version.override-with_maven_install-2.4 . Have fun. Rotsch - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Lightweight maven-releases, or an alternative to the maven-release-plugin
On 30 Apr 2013, at 11:21 PM, Roger Brechbühl rotscher...@gmail.com wrote: Maybe somebody is interested in how a release could be built in a more lightweight and safe way than with the maven-release-plugin. Especially recommended for nightly releases. It's not yet released, but basically fully working: *mvn clean install -Dversion.override=1.2.3-S-5* https://github.com/rotscher/emerging/tree/version.override-with_maven_install-2.4 Maven has a very clear definition of a release, being an artefact that can traced back to the precise code via a tag, and a build that can be repeated. This is as opposed to a snapshot, which has no well defined origin. You might approach this two ways, you might create nightly snapshots and have them deployed somewhere suitable, using mvn deploy. Alternatively if you want to create proper nightly releases (in the maven sense), you could feed a custom version number into the release plugin to represent your release, but this starts to smell like that's what a snapshot is for. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: Lightweight maven-releases, or an alternative to the maven-release-plugin
Graham, well said. Although the pom.xml is the easiest way to discover the version, it is not the best location, since it would require a commit. The solution must be found in a generated file which will be added to the artifact during packaging. Here you could add a timestamp or revision. Robert Op Wed, 01 May 2013 12:44:19 +0200 schreef Graham Leggett minf...@sharp.fm: On 30 Apr 2013, at 11:21 PM, Roger Brechbühl rotscher...@gmail.com wrote: Maybe somebody is interested in how a release could be built in a more lightweight and safe way than with the maven-release-plugin. Especially recommended for nightly releases. It's not yet released, but basically fully working: *mvn clean install -Dversion.override=1.2.3-S-5* https://github.com/rotscher/emerging/tree/version.override-with_maven_install-2.4 Maven has a very clear definition of a release, being an artefact that can traced back to the precise code via a tag, and a build that can be repeated. This is as opposed to a snapshot, which has no well defined origin. You might approach this two ways, you might create nightly snapshots and have them deployed somewhere suitable, using mvn deploy. Alternatively if you want to create proper nightly releases (in the maven sense), you could feed a custom version number into the release plugin to represent your release, but this starts to smell like that's what a snapshot is for. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Lightweight maven-releases, or an alternative to the maven-release-plugin
Hello there, I. find prepare and perform quite heavyweight my self. After prepare did build everything successfully, it throws away everything, just tags the source and starts over again during perform. prepare already checks with scm means, that there are no modifications and in my experience tagging is the most harmless operation in the whole process (well, would I still use CVS that could be different). So running prepare with prepareGoals set to -DperformRelease=true clean deploy does what *I* want. - checks I have everything in SCM - does modify POMs for release. - deploys to staging - only on success of this tags the sources - go back to SNAPSHOT. git and svn (when not doing the strange remoteTagging) are capable of tagging always. Worst thing that might happen: bad stuff in staging for a short time. Regards Mirko -- Sent from my mobile On May 1, 2013 9:15 PM, Robert Scholte rfscho...@apache.org wrote: Graham, well said. Although the pom.xml is the easiest way to discover the version, it is not the best location, since it would require a commit. The solution must be found in a generated file which will be added to the artifact during packaging. Here you could add a timestamp or revision. Robert Op Wed, 01 May 2013 12:44:19 +0200 schreef Graham Leggett minf...@sharp.fm: On 30 Apr 2013, at 11:21 PM, Roger Brechbühl rotscher...@gmail.com wrote: Maybe somebody is interested in how a release could be built in a more lightweight and safe way than with the maven-release-plugin. Especially recommended for nightly releases. It's not yet released, but basically fully working: *mvn clean install -Dversion.override=1.2.3-S-5* https://github.com/rotscher/**emerging/tree/version.** override-with_maven_install-2.**4https://github.com/rotscher/emerging/tree/version.override-with_maven_install-2.4 Maven has a very clear definition of a release, being an artefact that can traced back to the precise code via a tag, and a build that can be repeated. This is as opposed to a snapshot, which has no well defined origin. You might approach this two ways, you might create nightly snapshots and have them deployed somewhere suitable, using mvn deploy. Alternatively if you want to create proper nightly releases (in the maven sense), you could feed a custom version number into the release plugin to represent your release, but this starts to smell like that's what a snapshot is for. Regards, Graham -- --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Lightweight maven-releases, or an alternative to the maven-release-plugin
Hi all Maybe somebody is interested in how a release could be built in a more lightweight and safe way than with the maven-release-plugin. Especially recommended for nightly releases. It's not yet released, but basically fully working: *mvn clean install -Dversion.override=1.2.3-S-5* https://github.com/rotscher/emerging/tree/version.override-with_maven_install-2.4 . Have fun. Rotsch
RE: Lightweight maven-releases, or an alternative to the maven-release-plugin
Hi Rotch This sounds quite interesting and I feel it would be useful to a lot of projects. The release-plugin as it is, is not very flexible. Questions 1. Why does the jar need to be part of maven installation? Why not a plugin? 2. Can it generate a version based on some strategy? Looks like the version needs to be supplied through CLI parameter. 3. Some releases need a TAG in SCM while some releases don't require a TAG. Is there a possibility of having this functionality? 4. What happens if the release is trying to overwrite an already existing version on the repository? 5. What kind of formats are supported? jar, war etc. Thanks nambi -Original Message- From: Roger Brechbühl [mailto:rotscher...@gmail.com] Sent: Tuesday, April 30, 2013 2:22 PM To: users@maven.apache.org Subject: Lightweight maven-releases, or an alternative to the maven-release-plugin Hi all Maybe somebody is interested in how a release could be built in a more lightweight and safe way than with the maven-release-plugin. Especially recommended for nightly releases. It's not yet released, but basically fully working: *mvn clean install -Dversion.override=1.2.3-S-5* https://github.com/rotscher/emerging/tree/version.override-with_maven_install-2.4 . Have fun. Rotsch - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org