[ANNOUNCE] version.override feature (lightweight maven releases)
Dear Maven users, I improved the version.override feature so that the whole maven build life cycle is now properly supported: With *mvn clean deploy -Dversion.override* a build with an unique version is created without committing anything to your version control or making your workspace dirty. For more information read here: http://diplingfh.blogspot.ch/2013/09/lightweight-release-builds-with-apache.html Best regards, Roger
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
Re: Maven releases using Git
I don't know all commands by heart :-). And it also depends a bit on your project. should be something like: mvn release:branch -DbranchName=thatNewBranchYouWereDreamingAbout But fortunately, the doc is quite complete: http://maven.apache.org/maven-release/maven-release-plugin/branch-mojo.html But once again, if you what you want is releasing a product, then you already do the right thing. Doing a branch won't create a release, it's different. Cheers 2013/1/30 stadelma stade...@datazug.ch and what is the proper maven command? there are so many maven goals, and its hard to know em all. Josef -- View this message in context: http://maven.40175.n5.nabble.com/Maven-releases-using-Git-tp5744976p5745077.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: Maven releases using Git
Hi, It is expected behaviour. A release is actually like storing the state of your code for a precise event (often represented with a version). Maybe what you (also?) want is the release:branch goal. Cheers Le 29 janv. 2013 18:35, Jeff predato...@gmail.com a écrit : I've got my first GIT project to release using the maven release plugin, but it didn't create a branch like I would have expected, it simply tagged the current branch (master in my case) with the release version. Is this expected or am I missing something in my job config to make this happen? Thanks!! -- Jeff Vincent predato...@gmail.com See my LinkedIn profile at: http://www.linkedin.com/in/rjeffreyvincent I ♥ DropBox http://db.tt/9O6LfBX !!
Re: Maven releases using Git
and what is the proper maven command? there are so many maven goals, and its hard to know em all. Josef -- View this message in context: http://maven.40175.n5.nabble.com/Maven-releases-using-Git-tp5744976p5745077.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven releases during testing
Hi, I am using maven for web application development. As it is in development phase it is versioned as app-1.0-SNAPSHOT. But, application starts in couple of weeks, I was wondering what should be the best practise for release during tests. I believe only when it is tested and can go to production, then it is versioned to app-1.0. But, during testing how do we manage its versions? Thanks, Prashant
Re: maven releases during testing
release during tests. I believe only when it is tested and can go to production, then it is versioned to app-1.0. But, during testing how do we manage its versions? Just push a version out and call it 1.0-alpha-1 or -beta-1 or whatever. And test that version until you're happy with it. Keep changing (releasing versions) until you have things pretty well stabilized and you're happy with it then cut a release or just promote -beta-8 to be your production system and start on 1.1-SNAPSHOT. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven releases and multiple development streams
What is the standard guidelines or procedures for working with multiple development streams (ie, trunk, product_test, bugfix_on_version_x) and using the release plugin? For streams that are moving through the testing process, do you create the product_test branch and when that is complete do the maven release from the product_test branch then merge the new pom back into trunk? For fixing a bug in an already released version do you branch to bug_fix_... from tags and work with the (released) pom as is? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven releases?
When is the next maven released scheduled? It is 7 months since the last maven 2 release. Thanks, -Moiz
Re: Maven releases?
On 11/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: When is the next maven released scheduled? It is 7 months since the last maven 2 release. Is there a particular fix you're looking for? Most of what makes Maven work is in the plugins, and several of those have seen releases in the time since Maven 2.0.4 was released. If you're interested in when releases will happen, keep an eye on the development list. There has been some discussion of a 2.0.5 release, for example: http://www.nabble.com/Releasing-Maven-2.0.5-t2558719.html -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven releases?
Good day to you, Moiz, Furthermore, you can also take a look at the roadmap in [1] to see how much issues are left to be resolved before the next release. Upon making this post, there are now 77 out of 89 issues that have been resolved till the next release. Cheers, Franz [1] http://jira.codehaus.org/browse/MNG Wendy Smoak-3 wrote: On 11/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: When is the next maven released scheduled? It is 7 months since the last maven 2 release. Is there a particular fix you're looking for? Most of what makes Maven work is in the plugins, and several of those have seen releases in the time since Maven 2.0.4 was released. If you're interested in when releases will happen, keep an eye on the development list. There has been some discussion of a 2.0.5 release, for example: http://www.nabble.com/Releasing-Maven-2.0.5-t2558719.html -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Maven-releases--tf2580806s177.html#a7194461 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Notification about new Maven releases
announce@maven.apache.org lists all Maven-related releases (including plugins). announce@apache.org gets major releases (and all Apache releases). We have a freshmeat thing that's about 5 years old and I think we're locked out :) - Brett On 05/07/06, Jimisola Laursen [EMAIL PROTECTED] wrote: Hi! Is there a way to get a notification (email) when a new release of Maven is released? If not, would it be possible to add to project to freshmeat.net as they have this functionality and I assume many other use this for over projects? Regards, Jimisola -- View this message in context: http://www.nabble.com/Notification-about-new-Maven-releases-tf1890145.html#a5168026 Sent from the Maven - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Apache Maven - http://maven.apache.org Better Builds with Maven book - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
