Thanks for the responses, guys -
So, I can make a combination of these two plugins do what I need, in a
pinch:
<!-- this uses the buildnumber plugin to set a build
property to my SVN revision number -->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>buildnumber-maven-plugin</artifactId>
<executions>
<execution>
<phase>compile</phase>
<goals>
<goal>create</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- this causes the buildNumber to be written into the
MANIFEST.MF as SvnRevision -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<archive>
<index>true</index>
<manifestEntries>
<SvnRevision>${buildNumber}</SvnRevision>
</manifestEntries>
</archive>
</configuration>
</plugin>
so, my version number is in META-INF/maven/my.group/my.artifact/
pom.properties, and my SVN revision number is in META-INF/
MANIFEST.MF. This is a little annoying, since I don't really want to
have to go dig into my MANIFEST file at runtime to find out the
SvnRevision.
Is there a way to add additional properties to the generated
pom.properties? Getting those both in one place would simplify things
for me.
Actually, I wonder if it would make any sense to have a generic
"properties file" plugin, that allows you to generate an arbitrary
properties file from the context available to you at build time - so,
I could get exactly the behavior I described in my original post by
pulling in the buildnumber plugin as above, and then use the
theoretical propfile plugin like so:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>maven-propfile-plugin</artifactId>
<configuration>
<filename>${project.build.directory}/
version.properties</filename>
<properties>
<myproject.version>${project.version}</
myproject.version>
<myproject.revision>${buildNumber}</
myproject.revision>
</properties>
</configuration>
</plugin>
I could see good arguments for both of those solutions - either
allowing the user to specify additional build properties to be added
to pom.properties, or for having a plugin that generates a separate
properties file... any thoughts on either of those? I'd be happy to
look into doing either one, since they're both probably less work and
less gross than going digging for that information spread out across
multiple files at runtime...
and, of course, if there's already an elegant way to do what I really
want, let me know - I'm all for not writing redundant code... I've
already solved this problem in-elegantly with an antrun script, and
then after cutting and pasting that half a dozen times, I solved it
more elegantly with maven-rev-plugin, which I agree largely duplicates
functionality already available in buildnumber and/or the archiver...
But the combo of those two things still doesn't quite get me home, so
I'm trying to figure out where the gap in functionality (or my
understanding!) exists...
thanks!!
- Bryon
On May 13, 2008, at 4:49 AM, Mark Hobson wrote:
The Jar plugin already creates a project properties file for each
project under META-INF/maven/<groupId>/<artifactId>/pom.properties
that contains the project version number. You can use maven-runtime
to obtain this info at runtime, see:
http://svn.apache.org/repos/asf/maven/shared/trunk/maven-runtime
Mark
2008/5/13 Dan Tran <[EMAIL PROTECTED]>:
Great to hear new donation, however your plugin is very similar with
buildnumber-maven-plugin, i think
-D
On Mon, May 12, 2008 at 5:13 PM, Bryon Jacob <[EMAIL PROTECTED]> wrote:
I've got a plugin I'd like to donate to Mojo, if there's interest
- I've
named it rev-maven-plugin, and it's got one goal: properties
The plugin simply generates a properties file that contains a
property for
the maven project version number, and (optionally) the SVN
revision number.
We have used a similar thing on some other projects (just an
antrun script
that shelled out to "svn info", actually) to generate such a
properties file
for all of our HTTP services for a while - our applications load the
properties file, and expose a /version.txt URL so we can quickly
verify
exactly what version and SVN revision a running server in our
system is on
(the SVN revision number is particularly useful when we're deploying
SNAPSHOT builds to our staging servers...) Another use we've
found for it
is to incorporate the version and/or revision into group names
for a
cluster of servers that configures itself over UDP -- to make sure
that only
servers running the exact same version/revision of the code try to
coordinate. Basically, it's just taking a snapshot of this bit of
info
that's available at build time, and storing it off somewhere where
it can be
used at run time.
Anyways, after chatting with Jason at JavaOne last week, I thought
that this
might be something that the broader maven community might find
useful, so I
spent a bit of time coding it up as a proper mojo, and to use the
SvnKit
subversion library for java instead of the wanky shelling out to
SVN. It's
a tiny plugin, pretty simple to grok and use. The properties file
it
generates looks like:
yourproject/target/rev.properties
---------------------------------------------------------------------------------------------------
#revision properties for YourProject, generated by rev-maven-
plugin
#Mon May 12 16:31:24 CDT 2008
yourproject.revision=17
yourproject.version=2.0-SNAPSHOT
---------------------------------------------------------------------------------------------------
I think I've dotted all the i's to make it a well-behaved mojo
project (code
style, all the basics for the site, etc.), so if there's interest
I will zip
it up and submit a JIRA issue to create it in the sandbox.
thanks!
- Bryon
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
