You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by James Russo <jr...@halo3.net> on 2009/08/28 19:54:43 UTC
inject version into source?
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: inject version into source?
Posted by Stephen Connolly <st...@gmail.com>.
javac does not always do it with Strings. but it is more common if you
use arithmetic with constants... so
System.out.println("this is version "+Version.VERSION);
is more likely to get inlined than
System.out.print("this is version ");
System.out.println(Version.VERSION);
and if you have Version.MAJOR*100+Version.MINOR that will most likely
be inlined behind your back
Sent from my [rhymes with myPod] ;-)
On 29 Aug 2009, at 00:39, James Russo <jr...@halo3.net> wrote:
> Stephen,
>
> Thanks. I can honestly say I was not aware of that. I guess I
> hadn't been bitten by that one yet. Makes sense though..
>
> -jr
>
>
> Stephen Connolly wrote:
>> 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 <jr...@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.connolly@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 <jr...@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:dhicks@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-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
>>>>>>>
>>>>>>>
>>>>>>> ---
>>>>>>> ---
>>>>>>> ---------------------------------------------------------------
>>>>>>> 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
>>>>>>
>>>>
>>>> ---
>>>> ------------------------------------------------------------------
>>>> 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
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: inject version into source?
Posted by James Russo <jr...@halo3.net>.
Stephen,
Thanks. I can honestly say I was not aware of that. I guess I hadn't
been bitten by that one yet. Makes sense though..
-jr
Stephen Connolly wrote:
> 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 <jr...@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
>>> <st...@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 <jr...@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:dhicks@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-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
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> 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
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
> ---------------------------------------------------------------------
> 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
Re: inject version into source?
Posted by Stephen Connolly <st...@gmail.com>.
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 <jr...@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.connolly@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 <jr...@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:dhicks@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-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
>>>>>
>>>>>
>>>>> ---
>>>>> ------------------------------------------------------------------
>>>>> 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
>>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: inject version into source?
Posted by James Russo <jr...@halo3.net>.
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
> <st...@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 <jr...@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:dhicks@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-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
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>
> ---------------------------------------------------------------------
> 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
Re: inject version into source?
Posted by Stephen Connolly <st...@gmail.com>.
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.connolly@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 <jr...@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:dhicks@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-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
>>>
>>>
>>> ---
>>> ------------------------------------------------------------------
>>> 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
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: inject version into source?
Posted by Stephen Connolly <st...@gmail.com>.
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 <jr...@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:dhicks@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-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
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: inject version into source?
Posted by James Russo <jr...@halo3.net>.
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:dhicks@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-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
>
>
> ---------------------------------------------------------------------
> 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
RE: inject version into source?
Posted by "Lacoste, Dana (TSG Software San Diego)" <da...@hp.com>.
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:dhicks@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-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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: inject version into source?
Posted by "David C. Hicks" <dh...@i-hicks.org>.
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-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