the spec for javac allows directly including public static final
constants *by value* if they are one of the 8 primitives, or String.
so if another class (Foo.java) references Version.VERSION javac is
allowed to *copy* the string at *compile* time. if you subsequently
modify Version.java, but don't modify Foo.java then unless you delete
Foo.class, the old version number will still be embedded in Foo.class
if you don't believe me, give it a try. IDE's such as eclipse and
intellij guard against this early binding of public static final
constants by keeping track of dependent classes and fixing a recompile
if them. another route us to have a public static String noop(String v)
{return v;} in *another class* and define all your public static final
constants through this function thereby forcing evaluation when the
classes are loaded
Sent from my [rhymes with myPod] ;-)
On 28 Aug 2009, at 21:23, James Russo <j...@halo3.net> wrote:
Stephen,
Thanks. I think I will take this route. Not sure what you mean
about "partial build" though. If the .java file was updated each
time, it would be compiled each time.
Right now, I can't seem to get the build-version maven module to
fail if my local directory has modified code. docs say it should.
-jr
Stephen Connolly wrote:
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 <stephen.alan.conno...@gmail.com
> 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 <j...@halo3.net> 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:dhi...@i-hicks.org] 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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---
------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---
------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---
------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
