Re: buildnumber-plugin: sequential (increasing) build numbers with Git
Hi Karl-Heinz, in our specific case we build Magnolia modules http://documentation.magnolia-cms.com/reference/module-mechanism.html#Moduleversionhandling that have a module descriptor. The module descriptor contains a version number for that module, which tells the system at runtime whether an update of the module has occured (the system remembers the last installed version of each module). If the system detects a version update, it does run certain update routines for the encountered version delta of that module. Currently we bake the SVN revision gleaned from buildnumber-plugin into the module version number, triggering automatic updates. It is very convenient to have this happening on each developers' machine, not only on the CI server (each developer runs his own Magnolia instance): so when a developer performs an svn up the necessary update routines for other developers' changes will run on his Magnolia instance during hist next local build and run cycle. From what I understand of https://jira.codehaus.org/browse/MBUILDNUM-93 , a similar logic applies for Netbeans modules. So it is important here to be able to compare two given buildnumbers, which is not possible with the Git SHA only. Telling from the command prompt [torvalds@g5 git] in git-describe https://www.kernel.org/pub/software/scm/git/docs/git-describe.html, it seems that even the inventor of git does see sense in some kind of compound build numbers that include a commit number and short hash. Regards, Jörg On 29.04.2013 21:50, Karl Heinz Marbaise wrote: Hi Jörg, it's a common requirement to automatically have sequential (i.e. strictly increasing) version numbers being generated, e.g. based on SVN revision numbers. Such sequential version numbers can then be used for detection of updates of software modules, e.g. Netbeans modules or Magnolia modules. The only requirement I see in that relation ship is that you need a unique identifier for your packages which is usually mapped by using a tag (SVN/Git/ ...). This is represented by the version in your maven artifact. During the usual development you can use the -SNAPSHOT marker which internally is a timestamp which is independent of the used VCS (D or not D). To make things clear in that relationship the build-number is the revision number of the subversion repository which has nothing to do with a build-number. The equivalent for Git is simply the SHA1...nothing else... The best solution if you really need it use the BUILD_NUMBER environment from Jenkins/Hudson (other CI system's have similar things). The most important question which comes into my mind in that discussion is: Why do you need that build number and which purposes is behind that? Kind regards Karl-Heinz Marbaise -- *Dipl. inf. Jörg von Frantzius, System Architect* Email mailto:joerg.frantz...@aperto.de Phone +49 30 283921-318 Fax +49 30 283921-29 Aperto AG - In der Pianofabrik Chausseestraße 5, D-10115 Berlin-Mitte http://www.aperto.de http://www.facebook.com/aperto https://www.xing.com/companies/apertoag HRB 77049, AG Berlin Charlottenburg Vorstand: Dirk Buddensiek (Vorsitzender), Kai Großmann, Stephan Haagen Aufsichtsrat: Bernd Hardes (Vorsitzender)
Re: buildnumber-plugin: sequential (increasing) build numbers with Git
Hi Stephen, this could probably be handled by buildnumber-plugin using the SHA by default, and only given some optional parameter it would prefix it with the commit number? Out of curiosity, how exactly is the branch shared among the team? Using a shared filesystem? If everybody simply has a clone of that shared branch, my guess is that still nobody should change the history of already pushed commits. Regards, Jörg On 29.04.2013 20:56, Stephen Connolly wrote: So you don't see a team working on a shared branch and then squashing the 5 commits it took to fix FOO-345 and re-ordering commits before pushing to master? All this could take place on origin too... Not saying its recommended workflow, but tools should be defensive otherwise you have no tools when things go wrong On Monday, 29 April 2013, Jörg von Frantzius wrote: Hi Stephen, squashing commits and so decreasing build numbers should only affect builds from your local repository, as other people's or systems' builds can be affected only by pushing (and squashing commits after they were pushed is out of question, right?) Then how about counting commits only of the origin remote repo, which should not be affected by decreasing commit numbers? This would mean that build numbers can increase only on fetch from origin, which would be very similar to how things currently work with buildnumber-plugin and SVN. Technically it is of course possible to clone a repository where commits get squashed after cloning or fetching, but from my understanding that sounds like an insane setup. Regards, Jörg On 29.04.2013 15:28, Stephen Connolly wrote: I don't like it as squash and rebase can result in the number decreasing again. If you want strictly increasing numbers with DVCS systems you need either: 1. A central server that hands out build numbers (SPoF anyone?) or 2. A build number based on the system time (e.g. number of seconds since the release tag was cut) Basing the number on the commit distance from the last release tag will not help when people decide to re-order their commits and squash them down to merge them to master. I favour either releasing more often (thereby removing the need to hand -SNAPSHOTs around) or just changing the way you work. To my mind, the benefits that DVCS gives far far outweigh the loss of a commit number. YMMV and if you really cannot eliminate the need then you may be better suited to a non D VCS. [Others with stronger git-foo than me may have some nicer solutions] -Stephen On 29 April 2013 13:49, Jörg von Frantzius joerg.frantz...@aperto.de wrote: [Crossposting fromu...@mojo.codehaus.org, since no reply or other traffic over there...] Hi, it's a common requirement to automatically have sequential (i.e. strictly increasing) version numbers being generated, e.g. based on SVN revision numbers. Such sequential version numbers can then be used for detection of updates of software modules, e.g. Netbeans modules or Magnolia modules. While the buildnumber-plugin does provide this for Subversion, it doesn't do so for Git, and there is a corresponding open issue for the buildnumber-pluginhttps://jira.codehaus.org/browse/MBUILDNUM-93https://jira.codehaus.org/**browse/MBUILDNUM-93 https://**jira.codehaus.org/browse/**MBUILDNUM-93https://jira.codehaus.org/browse/MBUILDNUM-93 . There wasn't progress on that issue since a patch was supplied one year ago, and the problem with that patch seems to be that it replaces the currently used SHA entirely with the number of commits. Git itself does provide a similar feature with git describe ( https://www.kernel.org/pub/software/scm/git/docs/git- describe.htmlhttps://www.kernel.org/pub/**software/scm/git/docs/git-**describe.html https://www.**kernel.org/pub/software/scm/**git/docs/git-describe.htmlhttps://www.kernel.org/pub/software/scm/git/docs/git-describe.html ), where a buildnumber is composed from commit number followed by short SHA. A resulting artifact version would look like this: 1.0.4-14-g2414721, where 1.0.4 is a manually maintained version number, and 14-g2414721 is what the buildnumber plugin could generate. For the same Git branch, resulting version numbers are strictly increasing and can sensibly be compared and sorted. For different Git branches, or the same branch evolving differently in separated repositories, they at least remain distinguishable due to their SHA short hash. I'd be curious whether others also think that this approach would be suitable for the buildnumber plugin? Thanks for any thoughts, Jörg -- *Dipl. inf. Jörg von Frantzius, System Architect* Emailmailto:joerg.frantzius@aperto.**de joerg.frantz...@aperto.de Phone +49 30 283921-318 Fax +49 30 283921-29 Aperto AG - In der Pianofabrik Chausseestraße 5, D-10115 Berlin-Mitte http://www.aperto.de http://www.facebook.com/aperto https://www.xing.com/companies/apertoaghttps://www.xing.com/**companies/apertoag
Re: buildnumber-plugin: sequential (increasing) build numbers with Git
If you push the shared branch back to origin (yes bad practice I know... so requires that everyone involved knows that the foo-feature branch will have rewrites before merge back to master) Ordinarily you would mandate that once a commit is pushed upstream it will not be rewritten. But if you put in place a policy whereby you allow such rewrites during the merge back to master phase you can, via policy and procedures, allow such rewriting. I wouldn't be happy with such a usage myself, but I have seen people use that workflow quite successfully. On 30 April 2013 09:28, Jörg von Frantzius joerg.frantz...@aperto.dewrote: Hi Stephen, this could probably be handled by buildnumber-plugin using the SHA by default, and only given some optional parameter it would prefix it with the commit number? Out of curiosity, how exactly is the branch shared among the team? Using a shared filesystem? If everybody simply has a clone of that shared branch, my guess is that still nobody should change the history of already pushed commits. Regards, Jörg On 29.04.2013 20:56, Stephen Connolly wrote: So you don't see a team working on a shared branch and then squashing the 5 commits it took to fix FOO-345 and re-ordering commits before pushing to master? All this could take place on origin too... Not saying its recommended workflow, but tools should be defensive otherwise you have no tools when things go wrong On Monday, 29 April 2013, Jörg von Frantzius wrote: Hi Stephen, squashing commits and so decreasing build numbers should only affect builds from your local repository, as other people's or systems' builds can be affected only by pushing (and squashing commits after they were pushed is out of question, right?) Then how about counting commits only of the origin remote repo, which should not be affected by decreasing commit numbers? This would mean that build numbers can increase only on fetch from origin, which would be very similar to how things currently work with buildnumber-plugin and SVN. Technically it is of course possible to clone a repository where commits get squashed after cloning or fetching, but from my understanding that sounds like an insane setup. Regards, Jörg On 29.04.2013 15:28, Stephen Connolly wrote: I don't like it as squash and rebase can result in the number decreasing again. If you want strictly increasing numbers with DVCS systems you need either: 1. A central server that hands out build numbers (SPoF anyone?) or 2. A build number based on the system time (e.g. number of seconds since the release tag was cut) Basing the number on the commit distance from the last release tag will not help when people decide to re-order their commits and squash them down to merge them to master. I favour either releasing more often (thereby removing the need to hand -SNAPSHOTs around) or just changing the way you work. To my mind, the benefits that DVCS gives far far outweigh the loss of a commit number. YMMV and if you really cannot eliminate the need then you may be better suited to a non D VCS. [Others with stronger git-foo than me may have some nicer solutions] -Stephen On 29 April 2013 13:49, Jörg von Frantzius joerg.frantz...@aperto.de wrote: [Crossposting fromu...@mojo.codehaus.org, since no reply or other traffic over there...] Hi, it's a common requirement to automatically have sequential (i.e. strictly increasing) version numbers being generated, e.g. based on SVN revision numbers. Such sequential version numbers can then be used for detection of updates of software modules, e.g. Netbeans modules or Magnolia modules. While the buildnumber-plugin does provide this for Subversion, it doesn't do so for Git, and there is a corresponding open issue for the buildnumber-pluginhttps://jira**.codehaus.org/browse/** MBUILDNUM-93 http://jira.codehaus.org/browse/MBUILDNUM-93 https://jira.**codehaus.org/**browse/**MBUILDNUM-93https://jira.codehaus.org/**browse/MBUILDNUM-93 https://**jira.codehaus.org/**browse/**MBUILDNUM-93http://jira.codehaus.org/browse/**MBUILDNUM-93 https://**jira.codehaus.org/browse/**MBUILDNUM-93https://jira.codehaus.org/browse/MBUILDNUM-93 . There wasn't progress on that issue since a patch was supplied one year ago, and the problem with that patch seems to be that it replaces the currently used SHA entirely with the number of commits. Git itself does provide a similar feature with git describe ( https://www.kernel.org/pub/**software/scm/git/docs/git-**https://www.kernel.org/pub/software/scm/git/docs/git- describe.htmlhttps://www.**kernel.org/pub/**software/scm/** git/docs/git-**describe.htmlhttps://www.kernel.org/pub/**software/scm/git/docs/git-**describe.html https://www.**kernel.org/pub/**software/scm/**git/docs/git-** describe.htmlhttp://kernel.org/pub/software/scm/**git/docs/git-describe.html https://www.**kernel.org/pub/software/scm/**
Re: buildnumber-plugin: sequential (increasing) build numbers with Git
So I guess an optional parameter for buildnumber-plugin would be fine then? By default people using your described workflow wouldn't see problems, since they'd still use the SHA ony. On 30.04.2013 10:44, Stephen Connolly wrote: If you push the shared branch back to origin (yes bad practice I know... so requires that everyone involved knows that the foo-feature branch will have rewrites before merge back to master) Ordinarily you would mandate that once a commit is pushed upstream it will not be rewritten. But if you put in place a policy whereby you allow such rewrites during the merge back to master phase you can, via policy and procedures, allow such rewriting. I wouldn't be happy with such a usage myself, but I have seen people use that workflow quite successfully. On 30 April 2013 09:28, Jörg von Frantziusjoerg.frantz...@aperto.dewrote: Hi Stephen, this could probably be handled by buildnumber-plugin using the SHA by default, and only given some optional parameter it would prefix it with the commit number? Out of curiosity, how exactly is the branch shared among the team? Using a shared filesystem? If everybody simply has a clone of that shared branch, my guess is that still nobody should change the history of already pushed commits. Regards, Jörg On 29.04.2013 20:56, Stephen Connolly wrote: So you don't see a team working on a shared branch and then squashing the 5 commits it took to fix FOO-345 and re-ordering commits before pushing to master? All this could take place on origin too... Not saying its recommended workflow, but tools should be defensive otherwise you have no tools when things go wrong On Monday, 29 April 2013, Jörg von Frantzius wrote: Hi Stephen, squashing commits and so decreasing build numbers should only affect builds from your local repository, as other people's or systems' builds can be affected only by pushing (and squashing commits after they were pushed is out of question, right?) Then how about counting commits only of the origin remote repo, which should not be affected by decreasing commit numbers? This would mean that build numbers can increase only on fetch from origin, which would be very similar to how things currently work with buildnumber-plugin and SVN. Technically it is of course possible to clone a repository where commits get squashed after cloning or fetching, but from my understanding that sounds like an insane setup. Regards, Jörg On 29.04.2013 15:28, Stephen Connolly wrote: I don't like it as squash and rebase can result in the number decreasing again. If you want strictly increasing numbers with DVCS systems you need either: 1. A central server that hands out build numbers (SPoF anyone?) or 2. A build number based on the system time (e.g. number of seconds since the release tag was cut) Basing the number on the commit distance from the last release tag will not help when people decide to re-order their commits and squash them down to merge them to master. I favour either releasing more often (thereby removing the need to hand -SNAPSHOTs around) or just changing the way you work. To my mind, the benefits that DVCS gives far far outweigh the loss of a commit number. YMMV and if you really cannot eliminate the need then you may be better suited to a non D VCS. [Others with stronger git-foo than me may have some nicer solutions] -Stephen On 29 April 2013 13:49, Jörg von Frantzius joerg.frantz...@aperto.de wrote: [crosspostingfromu...@mojo.codehaus.org, since no reply or other traffic over there...] Hi, it's a common requirement to automatically have sequential (i.e. strictly increasing) version numbers being generated, e.g. based on SVN revision numbers. Such sequential version numbers can then be used for detection of updates of software modules, e.g. Netbeans modules or Magnolia modules. While the buildnumber-plugin does provide this for Subversion, it doesn't do so for Git, and there is a corresponding open issue for the buildnumber-pluginhttps://jira**.codehaus.org/browse/** MBUILDNUM-93http://jira.codehaus.org/browse/MBUILDNUM-93 https://jira.**codehaus.org/**browse/**MBUILDNUM-93https://jira.codehaus.org/**browse/MBUILDNUM-93 https://**jira.codehaus.org/**browse/**MBUILDNUM-93http://jira.codehaus.org/browse/**MBUILDNUM-93 https://**jira.codehaus.org/browse/**MBUILDNUM-93https://jira.codehaus.org/browse/MBUILDNUM-93 . There wasn't progress on that issue since a patch was supplied one year ago, and the problem with that patch seems to be that it replaces the currently used SHA entirely with the number of commits. Git itself does provide a similar feature with git describe ( https://www.kernel.org/pub/**software/scm/git/docs/git-**https://www.kernel.org/pub/software/scm/git/docs/git- describe.htmlhttps://www.**kernel.org/pub/**software/scm/** git/docs/git-**describe.htmlhttps://www.kernel.org/pub/**software/scm/git/docs/git-**describe.html
evaluation order of profiles
Hi, If in my pom I have this: [..] profile idprofile1/id activation [..make sure this profile is active..] /activation properties blah42/blah /properties /profile profile idprofile2/id activation [..make sure this profile is active..] /activation properties blah43/blah /properties /profile [..] Can I rely on it that the property blah will be 43 in the end? This boils down to the fact whether the evaluation order of profiles is always sequential or whether it can be random... Thanks, Kolos - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Testing jar files instead of class files
I would like to be able to achieve the following using two command line invocations: - build and install jar files using mvn install - run tests again, but against the installed jar files The rationale is that the first mvn run will only run unit tests (using test groups in TestNG), whereas the second mvn run would run all tests, including slow and database tests. In reality, both would be run from a CI server rather than a developer desktop. Clearly, the first mvn run is easy (I have that working). But I cannot see a way to run a mvn command that executes the tests against the installed jar files. The project is a multi-module project. Moving tests into a separate testing only project is not an acceptable approach. Running the slow/database tests as part of a single mvn run is not an acceptable approach. thanks for any thoughts or hyperlinks. Stephen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Testing jar files instead of class files
Well just to put this into context. What you actually want to do is run your second set of tests after the 'package' phase and before the 'install' phase. There is only the 'deploy' phase after the 'install' phase so there would be no scope to run tests after the 'install' phase. If you look at the lifecycle, you will see the handy: 'integration-test' and 'verify' phases. Now use of these phases is slightly different. Because you actually *never* want to type mvn integration-test and any time you think you do, you should actually type mvn verify in its place. The reason for this is that the pre-integration-test and post-integration-test phases are designed to allow setting up and tearing down the integration test environment, and, despite their names, the post-integration-test phase is *not* a finally block. So you need to be careful when binding plugins to the integration-test phase that such plugins *never* fail the build... At this point we have the Maven Failsafe Plugin enter the fray... this has two goals: failsafe:integration-test and failsafe:verify which, by default, bind to the integration-test and verify phases respectively. The `failsafe:integration-test` goal will run integration tests, but never fails the build. The `failsafe:verify` goal will check the results of `failsafe:integration-test` and fail the build if the tests fail. Thus you should be able to add failsafe to the mix by just adding plugin artifactIdmaven-failsafe-plugin/artifactId executions execution goals goalintegration-test/goal goalverify/goal /goals /execution /executions /plugin Now since failsafe is running after the `package` phase, it *should* be using the project artifact in place of target/classes *when* executed after the `package` phase... as all plugins should do... *but* I suspect there is a bug in failsafe that causes it to explicitly add target/classes. TL;DR it should be Maven Failsafe Plugin that gives this feature *but* I suspect there is a bug in that plugin that is causing it to use the directory in place of the .jar. Kristian, can you confirm my summary? -Stephen On 30 April 2013 12:11, Stephen Colebourne scolebou...@joda.org wrote: I would like to be able to achieve the following using two command line invocations: - build and install jar files using mvn install - run tests again, but against the installed jar files The rationale is that the first mvn run will only run unit tests (using test groups in TestNG), whereas the second mvn run would run all tests, including slow and database tests. In reality, both would be run from a CI server rather than a developer desktop. Clearly, the first mvn run is easy (I have that working). But I cannot see a way to run a mvn command that executes the tests against the installed jar files. The project is a multi-module project. Moving tests into a separate testing only project is not an acceptable approach. Running the slow/database tests as part of a single mvn run is not an acceptable approach. thanks for any thoughts or hyperlinks. Stephen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Testing jar files instead of class files
On 30 April 2013 12:28, Stephen Connolly stephen.alan.conno...@gmail.com wrote: What you actually want to do is run your second set of tests after the 'package' phase and before the 'install' phase. There is only the 'deploy' phase after the 'install' phase so there would be no scope to run tests after the 'install' phase. Thanks for the suggestion, but my question is around doing this in two separate command line invocations, not one. Iin a large multi-module build, I need to complete the full install for all modules (for speed). Only at that point do I want to stop and separately (perhaps on demand) run the additional tests. Unless what you're indicating is a way to run the second maven build without running the phases before integration-test? Stephen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Testing jar files instead of class files
Well how I normally do something like that is I put the failsafe execution in a profile, which by convention is called `run-its` So to build everything and install in the local repository cache: mvn install To build everything and install in the local repository cache with integration tests run: mvn -P+run-its install The second invokation will also rebuild the artifacts. Note I typically will have the release profile activate the integration tests also such that the integration tests are run on all release artifacts always. If, however, you want to be able to test the build artifacts without rebuilding them, then you really just need to factor the tests into a separate module and just run that module. So, you would have a separate module called integration-tests that has its tests added via the run-its profile mvn install will install everything (including the dummy integration-tests module) mvn -Prun-its -pl integration-tests verify will just run the integration tests module with the integration test profile added (so that this time the integration tests are run) On 30 April 2013 12:48, Stephen Colebourne scolebou...@joda.org wrote: On 30 April 2013 12:28, Stephen Connolly stephen.alan.conno...@gmail.com wrote: What you actually want to do is run your second set of tests after the 'package' phase and before the 'install' phase. There is only the 'deploy' phase after the 'install' phase so there would be no scope to run tests after the 'install' phase. Thanks for the suggestion, but my question is around doing this in two separate command line invocations, not one. Iin a large multi-module build, I need to complete the full install for all modules (for speed). Only at that point do I want to stop and separately (perhaps on demand) run the additional tests. Unless what you're indicating is a way to run the second maven build without running the phases before integration-test? Stephen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Testing jar files instead of class files
On 30 April 2013 13:20, Stephen Connolly stephen.alan.conno...@gmail.comwrote: Well how I normally do something like that is I put the failsafe execution in a profile, which by convention is called `run-its` So to build everything and install in the local repository cache: mvn install To build everything and install in the local repository cache with integration tests run: mvn -P+run-its install The second invokation will also rebuild the artifacts. Note I typically will have the release profile activate the integration tests also such that the integration tests are run on all release artifacts always. If, however, you want to be able to test the build artifacts without rebuilding them, then you really just need to factor the tests into a separate module and just run that module. So, you would have a separate module called integration-tests that has its tests added via the run-its profile mvn install will install everything (including the dummy integration-tests module) mvn -Prun-its -pl integration-tests verify will just run the integration tests module with the integration test profile added (so that this time the integration tests are run) The advantage of this way is that you are letting people who are on the Maven way continue the Maven way e.g. if I go from the root: mvn -Prun-its verify It will do what it is supposed to do: build everything and run the integration tests and you are still able to do what you want, all from the same set of poms and all without having to do anything other than standard maven patterns On 30 April 2013 12:48, Stephen Colebourne scolebou...@joda.org wrote: On 30 April 2013 12:28, Stephen Connolly stephen.alan.conno...@gmail.com wrote: What you actually want to do is run your second set of tests after the 'package' phase and before the 'install' phase. There is only the 'deploy' phase after the 'install' phase so there would be no scope to run tests after the 'install' phase. Thanks for the suggestion, but my question is around doing this in two separate command line invocations, not one. Iin a large multi-module build, I need to complete the full install for all modules (for speed). Only at that point do I want to stop and separately (perhaps on demand) run the additional tests. Unless what you're indicating is a way to run the second maven build without running the phases before integration-test? Stephen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: buildnumber-plugin: sequential (increasing) build numbers with Git
Hi Jörg, So I guess an optional parameter for buildnumber-plugin would be fine then? Adding an option (or better, populate a second Maven property) to buildnumber-maven-plugin makes sense to me. It would be potentially useful, not actively harmful, and based on what you said before, the work is largely complete. Right? -Curtis On Tue, Apr 30, 2013 at 3:53 AM, Jörg von Frantzius joerg.frantz...@aperto.de wrote: So I guess an optional parameter for buildnumber-plugin would be fine then? By default people using your described workflow wouldn't see problems, since they'd still use the SHA ony. On 30.04.2013 10:44, Stephen Connolly wrote: If you push the shared branch back to origin (yes bad practice I know... so requires that everyone involved knows that the foo-feature branch will have rewrites before merge back to master) Ordinarily you would mandate that once a commit is pushed upstream it will not be rewritten. But if you put in place a policy whereby you allow such rewrites during the merge back to master phase you can, via policy and procedures, allow such rewriting. I wouldn't be happy with such a usage myself, but I have seen people use that workflow quite successfully. On 30 April 2013 09:28, Jörg von Frantziusjoerg.frantzius@**aperto.dejoerg.frantz...@aperto.de wrote: Hi Stephen, this could probably be handled by buildnumber-plugin using the SHA by default, and only given some optional parameter it would prefix it with the commit number? Out of curiosity, how exactly is the branch shared among the team? Using a shared filesystem? If everybody simply has a clone of that shared branch, my guess is that still nobody should change the history of already pushed commits. Regards, Jörg On 29.04.2013 20:56, Stephen Connolly wrote: So you don't see a team working on a shared branch and then squashing the 5 commits it took to fix FOO-345 and re-ordering commits before pushing to master? All this could take place on origin too... Not saying its recommended workflow, but tools should be defensive otherwise you have no tools when things go wrong On Monday, 29 April 2013, Jörg von Frantzius wrote: Hi Stephen, squashing commits and so decreasing build numbers should only affect builds from your local repository, as other people's or systems' builds can be affected only by pushing (and squashing commits after they were pushed is out of question, right?) Then how about counting commits only of the origin remote repo, which should not be affected by decreasing commit numbers? This would mean that build numbers can increase only on fetch from origin, which would be very similar to how things currently work with buildnumber-plugin and SVN. Technically it is of course possible to clone a repository where commits get squashed after cloning or fetching, but from my understanding that sounds like an insane setup. Regards, Jörg On 29.04.2013 15:28, Stephen Connolly wrote: I don't like it as squash and rebase can result in the number decreasing again. If you want strictly increasing numbers with DVCS systems you need either: 1. A central server that hands out build numbers (SPoF anyone?) or 2. A build number based on the system time (e.g. number of seconds since the release tag was cut) Basing the number on the commit distance from the last release tag will not help when people decide to re-order their commits and squash them down to merge them to master. I favour either releasing more often (thereby removing the need to hand -SNAPSHOTs around) or just changing the way you work. To my mind, the benefits that DVCS gives far far outweigh the loss of a commit number. YMMV and if you really cannot eliminate the need then you may be better suited to a non D VCS. [Others with stronger git-foo than me may have some nicer solutions] -Stephen On 29 April 2013 13:49, Jörg von Frantzius joerg.frantz...@aperto.de wrote: [Crosspostingfromuser@mojo.**codehaus.orgcrosspostingfromu...@mojo.codehaus.org, since no reply or other traffic over there...] Hi, it's a common requirement to automatically have sequential (i.e. strictly increasing) version numbers being generated, e.g. based on SVN revision numbers. Such sequential version numbers can then be used for detection of updates of software modules, e.g. Netbeans modules or Magnolia modules. While the buildnumber-plugin does provide this for Subversion, it doesn't do so for Git, and there is a corresponding open issue for the buildnumber-pluginhttps://**jira**.codehaus.org/**browse/**http://codehaus.org/browse/** MBUILDNUM-93http://jira.**codehaus.org/browse/**MBUILDNUM-93http://jira.codehaus.org/browse/MBUILDNUM-93 https://jira.**codehaus.org/browse/**MBUILDNUM-93http://codehaus.org/**browse/**MBUILDNUM-93
Re: buildnumber-plugin: sequential (increasing) build numbers with Git
Hi Curtis, concerning the work being done already, there is a patch in https://jira.codehaus.org/browse/MBUILDNUM-93 that by default uses the commit number instead of the hash. So the remaining work would be to append the short hash to the commit number, and to make this behaviour optional. Unfortunately, I currently don't have resources to develop an improved patch. Hopefully I will if nobody else steps in for some time (weeks or months). And before even thinking of doing so, I wanted to be sure the patch simply won't get applied like the previous patch :) Regards, Jörg On 30.04.2013 16:17, Curtis Rueden wrote: Hi Jörg, So I guess an optional parameter for buildnumber-plugin would be fine then? Adding an option (or better, populate a second Maven property) to buildnumber-maven-plugin makes sense to me. It would be potentially useful, not actively harmful, and based on what you said before, the work is largely complete. Right? -Curtis On Tue, Apr 30, 2013 at 3:53 AM, Jörg von Frantzius joerg.frantz...@aperto.de wrote: So I guess an optional parameter for buildnumber-plugin would be fine then? By default people using your described workflow wouldn't see problems, since they'd still use the SHA ony. On 30.04.2013 10:44, Stephen Connolly wrote: If you push the shared branch back to origin (yes bad practice I know... so requires that everyone involved knows that the foo-feature branch will have rewrites before merge back to master) Ordinarily you would mandate that once a commit is pushed upstream it will not be rewritten. But if you put in place a policy whereby you allow such rewrites during the merge back to master phase you can, via policy and procedures, allow such rewriting. I wouldn't be happy with such a usage myself, but I have seen people use that workflow quite successfully. On 30 April 2013 09:28, Jörg von Frantziusjoerg.frantzius@**aperto.dejoerg.frantz...@aperto.de wrote: Hi Stephen, this could probably be handled by buildnumber-plugin using the SHA by default, and only given some optional parameter it would prefix it with the commit number? Out of curiosity, how exactly is the branch shared among the team? Using a shared filesystem? If everybody simply has a clone of that shared branch, my guess is that still nobody should change the history of already pushed commits. Regards, Jörg On 29.04.2013 20:56, Stephen Connolly wrote: So you don't see a team working on a shared branch and then squashing the 5 commits it took to fix FOO-345 and re-ordering commits before pushing to master? All this could take place on origin too... Not saying its recommended workflow, but tools should be defensive otherwise you have no tools when things go wrong On Monday, 29 April 2013, Jörg von Frantzius wrote: Hi Stephen, squashing commits and so decreasing build numbers should only affect builds from your local repository, as other people's or systems' builds can be affected only by pushing (and squashing commits after they were pushed is out of question, right?) Then how about counting commits only of the origin remote repo, which should not be affected by decreasing commit numbers? This would mean that build numbers can increase only on fetch from origin, which would be very similar to how things currently work with buildnumber-plugin and SVN. Technically it is of course possible to clone a repository where commits get squashed after cloning or fetching, but from my understanding that sounds like an insane setup. Regards, Jörg On 29.04.2013 15:28, Stephen Connolly wrote: I don't like it as squash and rebase can result in the number decreasing again. If you want strictly increasing numbers with DVCS systems you need either: 1. A central server that hands out build numbers (SPoF anyone?) or 2. A build number based on the system time (e.g. number of seconds since the release tag was cut) Basing the number on the commit distance from the last release tag will not help when people decide to re-order their commits and squash them down to merge them to master. I favour either releasing more often (thereby removing the need to hand -SNAPSHOTs around) or just changing the way you work. To my mind, the benefits that DVCS gives far far outweigh the loss of a commit number. YMMV and if you really cannot eliminate the need then you may be better suited to a non D VCS. [Others with stronger git-foo than me may have some nicer solutions] -Stephen On 29 April 2013 13:49, Jörg von Frantzius joerg.frantz...@aperto.de wrote: [Crosspostingfromuser@mojo.**codehaus.orgcrosspostingfromu...@mojo.codehaus.org, since no reply or other traffic over there...] Hi, it's a common requirement to automatically have sequential (i.e. strictly increasing) version numbers being generated, e.g. based on SVN revision numbers. Such sequential version numbers can then be used for detection of updates of software modules, e.g. Netbeans modules or Magnolia modules.
RE: Maven-release-plugin AND IBM RTC build engine...
Hi,
Actually it was Chris who helped me... Thanks Chris.
When I said NO access to RTC Build engine I meant for the physical server
where the build runs.
We have a support group that manages these servers which is why I don't have
the direct access.
(Yes that makes it more difficult to trouble shoot).
I am working with the local person to trouble shoot the issue.
The issue comes down to the scm -status command where on my laptop it works
fine but on the RTC build engine it gives below error.
We have defined
-DworkingDirectory = D:\temp\Maven (for the plugin working directory).
repository local directory =
localRepositoryD:\data\mavenrepo\ei_itam_discovery/localRepository
RTC load directory: load directory = ${BUILDWORKSPACE}\EI-Discovery2
[INFO] --- maven-release-plugin:2.4.1:prepare (default-cli) @ uCMDB-PatternDev
---
[INFO] Verifying that there are no local modifications...
[INFO] ignoring changes on: **\pom.xml.tag, **\pom.xml.branch,
**\pom.xml.releaseBackup, **\pom.xml.backup, **\release.properties,
**\pom.xml.next
[INFO] Executing: cmd.exe /X /C scm status --username srvrtcbuild --password
* --wide
[INFO] Working directory: D:\RTCBuildWorkspace\EI-Discovery2\EI AS-ITAM uCMDB
Pattern DEV
[ERROR] Error: Problem running 'status':
Current directory is not shared. Run from a shared directory.
Thanks,
Robert
-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
Sent: Monday, April 29, 2013 11:25 AM
To: Maven Users List
Subject: Re: Maven-release-plugin AND IBM RTC build engine...
Perhaps Chris Graham might be able to help... given that from what I
understand IBM decided not to let him go!!! Of course that assumes he has
access to the toolchain!
On 29 April 2013 16:07, Wayne Fay wayne...@gmail.com wrote:
I still DO NOT have the release plug-in working with RTC build engine.
...
work as well, unfortunately I don't have access to RTC build engine...
And this is exactly the reason why the release plugin does not work
with RTC build engine.
If you don't have access to RTC build engine, yet you are a customer
of IBM's and use their tools etc, how can any random open source
developer be granted the necessary access to these tools (Jazz, RTC,
etc) so the release plugin can be adapted as needed to work along with
it?
This is why Maven plugins for proprietary tools will ALWAYS lag in
functionality behind open source tools. For all intents, it
practically requires the VENDOR to put in the effort to build/adapt
the plugin for their products. If you have the ability to do so, I'd
open a bug/ticket with IBM and ask them to support the Maven release
plugin, otherwise I doubt this functionality will ever be added by
anyone else.
Wayne
-
To unsubscribe, e-mail: users-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: Maven-release-plugin AND IBM RTC build engine...
[INFO] Executing: cmd.exe /X /C scm status --username srvrtcbuild --password * --wide [INFO] Working directory: D:\RTCBuildWorkspace\EI-Discovery2\EI AS-ITAM uCMDB Pattern DEV Again, you probably need to ensure that all directories involved in the build do not have any spaces in the name. [ERROR] Error: Problem running 'status': Current directory is not shared. Run from a shared directory. I think that might be an error message from Jazz and not Maven. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven-release-plugin AND IBM RTC build engine...
If IBM were smart they would embrace Maven and do everything possible to support it well within Jazz. Maven does not really compete with anything IBM is doing, but it certainly compliments it in a positive way. I have met a few people in IBM who are sympathetic to better support for Maven, but I think some of the higher level decision makers need to be persuaded. Cheers, Eric On Tue, Apr 30, 2013 at 9:08 AM, Wayne Fay wayne...@gmail.com wrote: [INFO] Executing: cmd.exe /X /C scm status --username srvrtcbuild --password * --wide [INFO] Working directory: D:\RTCBuildWorkspace\EI-Discovery2\EI AS-ITAM uCMDB Pattern DEV Again, you probably need to ensure that all directories involved in the build do not have any spaces in the name. [ERROR] Error: Problem running 'status': Current directory is not shared. Run from a shared directory. I think that might be an error message from Jazz and not Maven. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven-release-plugin AND IBM RTC build engine...
Consider creating this directory D:\RTCBuildWorkspace\EI-Discovery2\EI and sharing it, then try again to see if your error message changes. It might help you to understand whether it's the directory name or the fact that it's not shared, as the message says. Shawn
RE: Maven-release-plugin AND IBM RTC build engine...
Hi Wayne, What I don't understand is that why would it work on my local laptop with the same directory names? I realize the working directory on the RTC build server uses the Component name (RTC term) which does have spaces in it. BTW: Thanks everyone for prompt responses... Robert -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: Tuesday, April 30, 2013 12:09 PM To: Maven Users List Subject: Re: Maven-release-plugin AND IBM RTC build engine... [INFO] Executing: cmd.exe /X /C scm status --username srvrtcbuild --password * --wide [INFO] Working directory: D:\RTCBuildWorkspace\EI-Discovery2\EI AS-ITAM uCMDB Pattern DEV Again, you probably need to ensure that all directories involved in the build do not have any spaces in the name. [ERROR] Error: Problem running 'status': Current directory is not shared. Run from a shared directory. I think that might be an error message from Jazz and not Maven. Wayne - To unsubscribe, e-mail: users-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
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
generating a POM and attaching it to the project
Hi all mates, I am in a situation where I need to generate a POM and, in order to have easily deployed/updated, I thought that having it attached in the project would have simplified the build process. The issue comes when external clients need to inherit from the generated pom, because classifiers are not supported in POMs inheritance... Do you have any suggestion to handle that situation? Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
Re: Maven-release-plugin AND IBM RTC build engine...
What I don't understand is that why would it work on my local laptop with the same directory names? I realize the working directory on the RTC build server uses the Component name (RTC term) which does have spaces in it. I couldn't even begin to guess. Clearly something is different between your local laptop and your build server. Wayne - 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 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
