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
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
