You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by ma...@leenarts.net on 2006/09/22 19:29:40 UTC
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/DefaultVersionInfo.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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Auto incrementing a build identifier
Posted by ma...@leenarts.net.
> A question about version numbering in Subversion.
>
Hu-hum, I worked too much today. Subversion should be Maven 2. I am using
Maven 2 on Subversion though.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Auto incrementing a build identifier
Posted by Julian Wood <wo...@ucalgary.ca>.
Hi,
I'm the author of the maven-buildnumber-plugin and have a few questions.
On 5-Aug-07, at 4:42 AM, Antony Stubbs wrote:
>
>
> The problem with Mavin buildnumber plugin, is that it isn't synced
> with the
> build number repository.
Can you clarify? I'm not sure what you mean at all. Do you mean you
can't get the source code for the plugin, for the released versions?
Or do you mean that the buildnumber isn't the same as the one in your
own svn repo? Maybe you don't have doUpdate=true specified in your
config (I can assure you will it grab the desired revision number if
configured correctly).
>
>>
>> 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.
Again, can you specify which ones? I'm not aware of any. It should
work exactly as it says in the docs, without any manual dependency
work whatsoever. But if you let me know the problems, I can fix them.
(There were some problems of this nature before it's first release,
but that was in January).
Here is the correct URL, btw.
http://commons.ucalgary.ca/projects/maven-buildnumber-plugin/index.html
Thanks and best,
J
--
Julian Wood
Web, E-Mail, and Middleware Services
University of Calgary Information Technologies,
2500 University Drive, Calgary, Alberta, Canada T2N 1N4
(403) 220-5868
RE: Auto incrementing a build identifier
Posted by Antony Stubbs <an...@gmail.com>.
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:antony.stubbs@gmail.com]
>> Sent: 05 August 2007 11:42
>> To: users@maven.apache.org
>> 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: maven@leenarts.net [mailto:maven@leenarts.net]
>>> Sent: Friday, September 22, 2006 8:30 PM
>>> To: users@maven.apache.org
>>> 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: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>
>> --
>> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
>
--
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Auto incrementing a build identifier
Posted by Antony Stubbs <an...@gmail.com>.
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:antony.stubbs@gmail.com]
> Sent: 05 August 2007 11:42
> To: users@maven.apache.org
> 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: maven@leenarts.net [mailto:maven@leenarts.net]
>> Sent: Friday, September 22, 2006 8:30 PM
>> To: users@maven.apache.org
>> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
> --
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Auto-incrementing-a-build-identifier-tf2319084s177.html#a12026347
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Auto incrementing a build identifier
Posted by John Coleman <jo...@eurobase-international.com>.
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:antony.stubbs@gmail.com]
Sent: 05 August 2007 11:42
To: users@maven.apache.org
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: maven@leenarts.net [mailto:maven@leenarts.net]
> Sent: Friday, September 22, 2006 8:30 PM
> To: users@maven.apache.org
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
--
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Auto incrementing a build identifier
Posted by Antony Stubbs <an...@gmail.com>.
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: maven@leenarts.net [mailto:maven@leenarts.net]
> Sent: Friday, September 22, 2006 8:30 PM
> To: users@maven.apache.org
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
--
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Auto incrementing a build identifier
Posted by Antony Stubbs <an...@gmail.com>.
Hi Juri,
This is great - but you may need to clarify legally how you are releasing
this code (if at all), if it's to be considered for Maven (i.e. Apache
commons license etc - could someone clarify what it would have to be?).
If not, it's food for thought - thanks! :)
Artamonov, Juri wrote:
>
> Hi Guys,
>
> Here is the plugin I wrote and use to distinguish two different
> snapshots.
> The properties I get and put into projectProperties can be used for
> example in Manifest.mf file storing build number or any other useful
> information. I would be glad if it helps you on your items.
>
>
> package com.fusionone.plugins;
>
>
> import org.apache.maven.artifact.Artifact;
> import org.apache.maven.artifact.manager.WagonManager;
> import org.apache.maven.artifact.repository.ArtifactRepository;
> import org.apache.maven.artifact.repository.metadata.Metadata;
> import org.apache.maven.artifact.repository.metadata.RepositoryMetadata;
> import
> org.apache.maven.artifact.repository.metadata.RepositoryMetadataManager;
> import
> org.apache.maven.artifact.repository.metadata.RepositoryMetadataResoluti
> onException;
> import
> org.apache.maven.artifact.repository.metadata.SnapshotArtifactRepository
> Metadata;
> import org.apache.maven.plugin.AbstractMojo;
> import org.apache.maven.plugin.MojoExecutionException;
> import org.apache.maven.plugin.MojoFailureException;
> import org.apache.maven.project.MavenProject;
> import org.codehaus.plexus.util.StringUtils;
>
> import java.io.File;
> import java.text.SimpleDateFormat;
> import java.util.Date;
> import java.util.Iterator;
> import java.util.List;
>
>
> /**
> * Goal which get new build number version.
> *
> * @goal create
> * @phase compile
> */
> public class BuildNumberMojo
> extends AbstractMojo
> {
> /**
> * Location of the file.
> * @parameter expression="${project.build.directory}"
> * @required
> */
> private File outputDirectory;
> /**
> * The maven project.
> *
> * @parameter expression="${project}"
> * @required
> * @readonly
> */
> private MavenProject project;
>
> /**
> * @parameter expression="${project.artifact}"
> * @required
> * @readonly
> */
> private Artifact artifact;
>
> /**
> * Local maven repository.
> *
> * @parameter expression="${localRepository}"
> * @required
> * @readonly
> */
> protected ArtifactRepository localRepository;
>
> /**
> * Remote repositories which will be searched for source
> attachments.
> *
> * @parameter expression="${project.remoteArtifactRepositories}"
> * @required
> * @readonly
> */
> protected List remoteArtifactRepositories;
>
> private WagonManager wagonManager;
>
> /**
> * Repository meta data.
> *
> * @component
> role="org.apache.maven.artifact.repository.metadata.RepositoryMetadataMa
> nager"
> * @required
> * @readonly
> */
>
> protected RepositoryMetadataManager repositoryMetadataManager;
>
> public void execute() throws MojoExecutionException,
> MojoFailureException {
>
>
> String buildNumber = null;
> String date = null;
> try
> {
> buildNumber = resolveLatestSnapshotBuildNumber( artifact,
> localRepository, remoteArtifactRepositories );
> SimpleDateFormat sdf = new SimpleDateFormat();
> date = sdf.format(new Date());
> }
> catch (RepositoryMetadataResolutionException e)
> {
> e.printStackTrace();
> }
>
> if ( project != null )
> {
> getLog().info( "Storing buildNumber: " + buildNumber );
> project.getProperties().put("buildNumber", buildNumber);
> project.getProperties().put("date", date);
>
> }
> }
>
> public void execute(Artifact artifact, ArtifactRepository
> localRepository, List remoteArtifactRepositories,
> MavenProject project, RepositoryMetadataManager
> repositoryMetadataManager) throws MojoExecutionException,
> MojoFailureException
> {
> this.artifact = artifact;
> this.localRepository = localRepository;
> this.remoteArtifactRepositories = remoteArtifactRepositories;
> this.project = project;
> this.repositoryMetadataManager = repositoryMetadataManager;
> execute();
> }
>
> private String resolveLatestSnapshotBuildNumber( Artifact artifact,
> ArtifactRepository localRepository,
> List remoteRepositories )
> throws RepositoryMetadataResolutionException
> {
> ArtifactRepository remoteRepository = null;
> RepositoryMetadata metadata = new
> SnapshotArtifactRepositoryMetadata( artifact );
> for (Iterator it = remoteRepositories.iterator(); it.hasNext();)
> {
> remoteRepository = (ArtifactRepository) it.next();
> repositoryMetadataManager.resolveAlways( metadata,
> localRepository, remoteRepository);
> }
>
> // repositoryMetadataManager.resolveAlways( metadata,
> localRepository, remoteRepository);
>
> int buildNumber = 0;
> Metadata repoMetadata = metadata.getMetadata();
> if ( ( repoMetadata != null )
> && ( repoMetadata.getVersioning() != null &&
> repoMetadata.getVersioning().getSnapshot() != null ) )
> {
> //getLog().info( "timestamp " +
> repoMetadata.getVersioning().getSnapshot().getTimestamp() );
> buildNumber =
> repoMetadata.getVersioning().getSnapshot().getBuildNumber();
> }
> return constructBuildNumber(buildNumber,
> artifact.getBaseVersion());
> }
>
> private String constructBuildNumber(int buildNumber, String
> baseVersion)
> {
> buildNumber = buildNumber + 1;
> return StringUtils.replace(baseVersion, "-SNAPSHOT", "." +
> String.valueOf(buildNumber));
> }
>
> }
>
> Best regards,
> Juri.
>
> -----Original Message-----
> From: Antony Stubbs [mailto:antony.stubbs@gmail.com]
> Sent: Tuesday, August 07, 2007 3:43 AM
> To: users@maven.apache.org
> Subject: RE: Auto incrementing a build identifier
>
>
> 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:antony.stubbs@gmail.com]
>>> Sent: 05 August 2007 11:42
>>> To: users@maven.apache.org
>>> 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: maven@leenarts.net [mailto:maven@leenarts.net]
>>>> Sent: Friday, September 22, 2006 8:30 PM
>>>> To: users@maven.apache.org
>>>> 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: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>>
>>> --
>>> 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: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>> 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: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>
>>
>
> --
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Auto-incrementing-a-build-identifier-tf2319084s177.html#a12049162
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org