another way is to store the version in the manifest and then retrieve
the manifest from the classloader for the class you are loading... of
course the downside is that if somebody makes an uberjar you'll have
the version of the uberjar and nit the version of the code that was
uberjarred (which is why the properties file is the recommended route.)
btw a static string constant in a file, eg Version.java will only get
updated on a full clean build, so if you do a partial build, the
version number would not get updated... yet another reason why
properties files are preferred
Sent from my [rhymes with myPod] ;-)
On 28 Aug 2009, at 20:42, Stephen Connolly <[email protected]
> wrote:
turn on filtering for a specific resource (e.g. com/foo/bar/
Version.properties)
have this file with the contents
version=${project.version}
replace your com.foo.bar.Version.java with code like so
public static String getVersion() {
InputStream is = Version.class.getResource("Version.properties");
Properties props = new Properties();
props.loadFromStream(is);
return props.getProperty("version");
}
obviously, add caching and error handling (no smart completion on
the iPod)
-Stephen
Sent from my [rhymes with myPod] ;-)
On 28 Aug 2009, at 19:18, James Russo <[email protected]> wrote:
Dana,
Thanks. That is fine. I am fine with just injecting the <version>
value of the pom, but I need it accessible to my application.
Current scheme for
this is to have it in a Version.java file as a static string which
is referenced for display in the application.
Still trying to get my head around all this stuff. My application
went from one big war file to now having a few jar files and one
simple maven war
project which includes all the others. Going to be building them
all at the same time, so they should all have the same version/
build number. Thats on
my list too, how to get all sub modules to inherit version number
from the parent pom. Thinking I just leave it out of the module
poms, haven't tried that yet.
I was planning on looking at the maven-release plugin to generate
real releases of my application... Don't use perforce though.
-jr
Lacoste, Dana (TSG Software San Diego) wrote:
So, basically, you use a "wrapper" to get around maven?
I do something similar: I use a .properties file, then run
an <xmltask> ant script to update the maven pom.xml files.
Very predictable, very manageable, and bypasses the
maven-release-plugin which caused ALL KINDS of headaches
because it doesn't work with perforce properly.
James, that'd be my recommendation: update the maven info
to fit your build before you run maven :)
Dana Lacoste
-----Original Message-----
From: David C. Hicks [mailto:[email protected]] Sent: Friday,
August 28, 2009 11:01 AM
To: Maven Users List
Subject: Re: inject version into source?
I have done this by setting up a properties file that gets
filtered at
build time. Then, I use that properties file in a Spring
PlaceholderConfigurer to get the value injected where I need it.
James Russo wrote:
Hello,
New maven user here. Really am liking it, just trying to get
project back online and running after switching from ant.. Is there
any standard maven way to inject maven variables (like version)
into
source code, prior to compile? Is this maybe were I should just
leverage my existing any scripts to accomplish the task?
thanks,
-jr
---
------------------------------------------------------------------
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]
---
------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
