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:[EMAIL PROTECTED]
> 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:[EMAIL PROTECTED]
>>> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>>>> 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: [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]
>
>
> ---------------------------------------------------------------------
> 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#a12049162
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
