I have submitted a jira issue [1] - let's see what response we get... A work around I am going to try, is pretty much ignoring the build number that deploy generates, and instead rely on time stamps. E.g. I will use the timestamp generated by build number plugin in a properties file to display in the application - this should match up with the build timestamp used by deploy. I will have to make sure the build number plugin uses 0 GMT though.
[1] http://jira.codehaus.org/browse/MDEPLOY-60 Antony Stubbs wrote: > > Apparently you can do that ( I haven't tried it ) using the > build-number-plugin, but again, not into the _deploy_ artefact. That > plugin still has it's own system for putting a build number in the file > name. it's a real pity - I wonder how this hasn't been addressed in the > past. > I mean, what do most people do to represent the current running build of a > snapshot, inside the application, and in the filename? > > > John Coleman-6 wrote: >> >> That certainly gets my vote - just last week I was thinking it might be >> handy to incorporate the subversion revision number in the artefact >> name. >> >> John >> >> -----Original Message----- >> From: Antony Stubbs [mailto:[EMAIL PROTECTED] >> Sent: 05 August 2007 11:42 >> To: [email protected] >> Subject: RE: Auto incrementing a build identifier >> >> >> That's exactly what M2 needs - would you consider releasing your mojo? >> I'd >> love to try using. >> IMO this should be apart of the m2 deploy goal. >> >> The problem with Mavin buildnumber plugin, is that it isn't synced with >> the >> build number repository. >> >> >> Artamonov, Juri wrote: >>> >>>>The thing is that I don't want to generate "new" builds during >>> development, overwriting the current snapshot is preferred. But when >>> processing a project which will be "publicly" available, I want to be >>> able to identify it >(even a snapshot) with an incremented build >> number, >>> but without having to manage the version setting by hand. >>> >>> IMHO, this is (I mean let's say snapshot numbering) not yet covered >> well >>> in m2. >>> >>> I have requirement also for myself to distunguish two snapshot builds >>> and here is what I did... >>> >>> 1. I use maestro stuff with continuum and m2. When I do install I have >>> files like 1.0-SNPASHOT-<BUILD_NUMBER> in repository. BUILD_NUMBER is >>> always inrementing on 1 when new version is installed into repository. >>> 2. I wrote the plugin which get latest BUILD_NUMBER from repository >> and >>> do +1 during for example compile phase. Now I know what build version >> is >>> going to be and I put this information into manifest file or war file >> or >>> for example jar file. Now I have information inside of the archive >> that >>> allows me to distinguish two snapshot versions. >>> >>> Also you can use >>> http://commons.ucalgary.ca/projects/maven-buildnumber-plugin/ plugin >> but >>> seems having it working requires a lot of manual work, due missing >>> versions on the repositories of the components listed in the >>> dependencies. >>> >>> Best regards, >>> Juri. >>> >>> -----Original Message----- >>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >>> Sent: Friday, September 22, 2006 8:30 PM >>> To: [email protected] >>> Subject: Auto incrementing a build identifier >>> >>> >>> A question about version numbering in Subversion. >>> >>> I am aware of the way subversion handles version information while >>> releasing. As I have peeked overhere in the Maven repository: >>> >>> >> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-release-plugin >>> >> -2.0-beta-4/src/main/java/org/apache/maven/plugins/release/versions/Defa >>> ultVersionInfo.java >>> >>> Now I am wondering about something. My current contract would like a >>> build increment value in between two brackets. Which auto increases >> with >>> each build delivered to production. I'd say that hooking into the >> deploy >>> phase would be a good time for such actions. But then I figure that it >>> isn't. >>> >>> I'd say the initialize phase is the correct one. Since I am not >>> processing resources or sources but the POM.xml. The thing is this, >> can >>> I modify the POM then and there and keep the build going or do I need >> to >>> modify the POM. And let the user start another run, just like the >>> release plugin does? >>> >>> Also, is it possible (by documented API or acceptable convention) to >>> detect whether or not a build is running up to or past the deploy >> phase? >>> >>> The thing is that I don't want to generate "new" builds during >>> development, overwriting the current snapshot is preferred. But when >>> processing a project which will be "publicly" available, I want to be >>> able to identify it (even a snapshot) with an incremented build >> number, >>> but without having to manage the version setting by hand. >>> >>> Any suggestions are greatly apreciated. >>> >>> Kind regards, >>> Jeroen Leenarts >>> http://blog.leenarts.net >>> >>> Download this as a file >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Auto-incrementing-a-build-identifier-tf2319084s177 >> .html#a12003652 >> Sent from the Maven - Users mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> Eurobase International Limited and its subsidiaries (Eurobase) are unable >> to exercise control over the content of information in E-Mails. Any views >> and opinions expressed may be personal to the sender and are not >> necessarily those of Eurobase. Eurobase will not enter into any >> contractual obligations in respect of any part of its business in any >> E-mail. >> >> Privileged / confidential information may be contained in this message >> and /or any attachments. This E-mail is intended for the use of the >> addressee(s) only and may contain confidential information. If you are >> not the / an intended recipient, you are hereby notified that any use or >> dissemination of this communication is strictly prohibited. If you >> receive this transmission in error, please notify us immediately, and >> then delete this E-mail. >> >> Neither the sender nor Eurobase accepts any liability whatsoever for any >> defects of any kind either in or arising from this E-mail transmission. >> E-Mail transmission cannot be guaranteed to be secure or error-free, as >> messages can be intercepted, lost, corrupted, destroyed, contain viruses, >> or arrive late or incomplete. Eurobase does not accept any responsibility >> for viruses and it is your responsibility to scan any attachments. >> >> Eurobase Systems Limited is the main trading company in the Eurobase >> International Group; registered in England and Wales as company number >> 02251162; registered address: Essex House, 2 County Place, Chelmsford, >> Essex CM2 0RE, UK. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > -- View this message in context: http://www.nabble.com/Auto-incrementing-a-build-identifier-tf2319084s177.html#a12026703 Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
