You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Al...@miranda.com on 2014/07/16 20:18:01 UTC
move data from pom to class or class to pom
I have a java class that has a constant in it (static final String). This
string is a version number, e.g. "1.3.2-test". I need to have this same
value in a maven plugin configuration (the jaxb plugin) so I am wondering,
is it better to keep the actual declaration in the code and somehow tell
maven to take it from the code, or is it better to declare it in the pom
and tell java to take the literal value to define the constant from the
pom??
I don't know how to do either so I would also like to hear some ideas. I
am hoping i don't have to use resource filtering since having a source
file as a resource is kind of problematic to me. It has to be ONLY that
file that gets filtered, it would need to be in a non-standard location
not src/main/java (maybe this is not true), and in general, it seems to me
that treating source code as resource is counter-intuitive
Has anyone else solved this issue with the DRY principle across behaviour
and build system?
The short background is that maven generates an XML schema via jaxb and
this schema file is then made available at runtime via a service
Thank you,
Alejandro Endo | Software Designer/Concepteur de logiciels
DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.
Re: move data from pom to class or class to pom
Posted by Robert Scholte <rf...@apache.org>.
http://mojo.codehaus.org/templating-maven-plugin/ is probably the best
matching solution for you.
thanks,
Robert
Op Wed, 16 Jul 2014 20:18:01 +0200 schreef <Al...@miranda.com>:
> I have a java class that has a constant in it (static final String). This
> string is a version number, e.g. "1.3.2-test". I need to have this same
> value in a maven plugin configuration (the jaxb plugin) so I am
> wondering,
> is it better to keep the actual declaration in the code and somehow tell
> maven to take it from the code, or is it better to declare it in the pom
> and tell java to take the literal value to define the constant from the
> pom??
>
> I don't know how to do either so I would also like to hear some ideas. I
> am hoping i don't have to use resource filtering since having a source
> file as a resource is kind of problematic to me. It has to be ONLY that
> file that gets filtered, it would need to be in a non-standard location
> not src/main/java (maybe this is not true), and in general, it seems to
> me
> that treating source code as resource is counter-intuitive
>
> Has anyone else solved this issue with the DRY principle across behaviour
> and build system?
>
> The short background is that maven generates an XML schema via jaxb and
> this schema file is then made available at runtime via a service
>
> Thank you,
>
> Alejandro Endo | Software Designer/Concepteur de logiciels
>
>
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
> Thank You.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: move data from pom to class or class to pom
Posted by Curtis Rueden <ct...@wisc.edu>.
Hi Alejandro,
> In my case the constant is package protected (it would be private
> if it wasn't because i need it in unit tests)
Right, so the only (hopefully unlikely) problem would be a class in the
same package but in a different JAR relying on the value. If it is a
serious concern you can write the constant as "new String(...)" to avoid
the inlining.
-Curtis
On Wed, Jul 16, 2014 at 1:43 PM, <Al...@miranda.com> wrote:
> Hi Curtis,
>
> I *think* i see you point, but wouldn't that happen ONLY if the constant
> is public and referenced in a separate jar?? where it would be inlined in
> the referring class (right?). In my case the constant is package protected
> (it would be private if it wasn't because i need it in unit tests)
>
> The problem with defining it in the manifest is that I use this constant
> in the property of an annotation of the class
>
> @StaticServiceProperty(mandatory = true, type = "java.lang.String", name =
> "schemaVersion", value = SchemaProviderServiceImpl.SCHEMA_VERSION,
> immutable = true)
> public class SchemaProviderServiceImpl
>
> so I can't grab it from the manifest at runtime. I guess the way I phrased
> it in the original email implied the opposite, sorry about that
>
> Alejandro Endo | Software Designer/Concepteur de logiciels
>
>
>
>
>
> From: Curtis Rueden <ct...@wisc.edu>
> To: Maven Users List <us...@maven.apache.org>,
> Date: 2014-07-16 14:27
> Subject: Re: move data from pom to class or class to pom
> Sent by: ctrueden.wisc@gmail.com
>
>
>
> Hi Alejandro,
>
> > I have a java class that has a constant in it (static final String).
> > This string is a version number, e.g. "1.3.2-test".
>
> Beware: the Java compiler often inlines constants, _including String
> constants_, into classes that reference the value. So if you compile a
> class "Foo" against version 1 of library "bar", then run with version 2 of
> "bar" in the classpath, Foo will still see the constant value as 1 instead
> of 2.
>
> http://javasplitter.blogspot.com/2011/10/static-final-inline-trap.html
>
> Much, much better to embed the version number into the JAR manifest,
> and/or
> read it out of the Maven POM which the maven-jar-plugin embeds in the JAR
> file.
>
> Regards,
> Curtis
>
>
> On Wed, Jul 16, 2014 at 1:18 PM, <Al...@miranda.com> wrote:
>
> > I have a java class that has a constant in it (static final String).
> This
> > string is a version number, e.g. "1.3.2-test". I need to have this same
> > value in a maven plugin configuration (the jaxb plugin) so I am
> wondering,
> > is it better to keep the actual declaration in the code and somehow tell
> > maven to take it from the code, or is it better to declare it in the pom
> > and tell java to take the literal value to define the constant from the
> > pom??
> >
> > I don't know how to do either so I would also like to hear some ideas. I
> > am hoping i don't have to use resource filtering since having a source
> > file as a resource is kind of problematic to me. It has to be ONLY that
> > file that gets filtered, it would need to be in a non-standard location
> > not src/main/java (maybe this is not true), and in general, it seems to
> me
> > that treating source code as resource is counter-intuitive
> >
> > Has anyone else solved this issue with the DRY principle across
> behaviour
> > and build system?
> >
> > The short background is that maven generates an XML schema via jaxb and
> > this schema file is then made available at runtime via a service
> >
> > Thank you,
> >
> > Alejandro Endo | Software Designer/Concepteur de logiciels
> >
> >
> > DISCLAIMER:
> > Privileged and/or Confidential information may be contained in this
> > message. If you are not the addressee of this message, you may not
> > copy, use or deliver this message to anyone. In such event, you
> > should destroy the message and kindly notify the sender by reply
> > e-mail. It is understood that opinions or conclusions that do not
> > relate to the official business of the company are neither given
> > nor endorsed by the company.
> > Thank You.
> >
>
>
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
> Thank You.
>
Re: move data from pom to class or class to pom
Posted by Benson Margulies <bi...@gmail.com>.
There is a very simple process here. Turn on filtering in the resource
plugin, and add a .properties file that filters in what you need. Then
get those properties. No problems with unit tests, no problems keeping
track of _which_ MANIFEST.MF from classpath is the one you need.
On Fri, Jul 18, 2014 at 4:33 PM, Karl Heinz Marbaise <kh...@gmx.de> wrote:
> Hi Jörg,
>
>>
>>
>> nice article ;-)
>>
>> There's one comment I do not understand though:
>>
>>> The main disadvantage of this approach is that you can only use the
>>> Implementation and Specification parts of your MANIFEST.MF file which
>>> might be enough in some situations but not in all.
>
>
> The comment is related to the implementation in Java which allows only to
> extract the implementation and specification part...via
> this.getClass().getPackage()....
>
> http://docs.oracle.com/javase/7/docs/api/java/lang/Package.html
> So can't use that in a very simple way...
>
>>
>> You can add all kind of entries to the manifest. You may even overwrite
>> the
>> defaults. We use typically:
>
>
> Of course you can so create an appropriate MANIFEST.MF file...
>
>>
>> ===================== %< ======================
>> <archive>
>> <manifest>
>>
>> <addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
>>
>> <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
>> </manifest>
>> <manifestEntries>
>> <Specification-Version>${parsedVersion.majorVersion}.
>> ${parsedVersion.minorVersion}</Specification-Version>
>> <X-Compile-Source>${java.version.source}</X-Compile-Source>
>> <X-Compile-Target>${java.version.target}</X-Compile-Target>
>> <X-Builder>Maven ${maven.version}</X-Builder>
>> <X-Build-Time>${maven.build.timestamp}</X-Build-Time>
>> <X-Build-Os>${os.name}</X-Build-Os>
>> </manifestEntries>
>> </archive>
>> ===================== %< ======================
>>
>> With the $parsedVersion and $maven.version variables provided by the
>> build-
>> helper plugin.
>
> But the above entries can't be read via methods which already exists like
> getPackage()....
>
> So you need to implement it your own...you have to take care about
> classloading issue (classloaders in particular in larger apps etc.)...
> so it get more and more complicated...lets talk about apps which comprise of
> 150 jar files...
>
> So the simplest Solution is to use the templating-maven-plugin which solves
> many of those issues.
>
> Kind regards
> Karl-Heinz Marbaise
>
>
> ---------------------------------------------------------------------
> 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: move data from pom to class or class to pom
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi Jörg,
>
> nice article ;-)
>
> There's one comment I do not understand though:
>
>> The main disadvantage of this approach is that you can only use the
>> Implementation and Specification parts of your MANIFEST.MF file which
>> might be enough in some situations but not in all.
The comment is related to the implementation in Java which allows only
to extract the implementation and specification part...via
this.getClass().getPackage()....
http://docs.oracle.com/javase/7/docs/api/java/lang/Package.html
So can't use that in a very simple way...
>
> You can add all kind of entries to the manifest. You may even overwrite the
> defaults. We use typically:
Of course you can so create an appropriate MANIFEST.MF file...
>
> ===================== %< ======================
> <archive>
> <manifest>
> <addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
> <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
> </manifest>
> <manifestEntries>
> <Specification-Version>${parsedVersion.majorVersion}.
> ${parsedVersion.minorVersion}</Specification-Version>
> <X-Compile-Source>${java.version.source}</X-Compile-Source>
> <X-Compile-Target>${java.version.target}</X-Compile-Target>
> <X-Builder>Maven ${maven.version}</X-Builder>
> <X-Build-Time>${maven.build.timestamp}</X-Build-Time>
> <X-Build-Os>${os.name}</X-Build-Os>
> </manifestEntries>
> </archive>
> ===================== %< ======================
>
> With the $parsedVersion and $maven.version variables provided by the build-
> helper plugin.
But the above entries can't be read via methods which already exists
like getPackage()....
So you need to implement it your own...you have to take care about
classloading issue (classloaders in particular in larger apps etc.)...
so it get more and more complicated...lets talk about apps which
comprise of 150 jar files...
So the simplest Solution is to use the templating-maven-plugin which
solves many of those issues.
Kind regards
Karl-Heinz Marbaise
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: move data from pom to class or class to pom
Posted by Jörg Schaible <jo...@swisspost.com>.
Hi Karl-Heinz,
Karl Heinz Marbaise wrote:
> Hi,
>
> > Move the Java code that should contain the version into an own
> > directory
>> tree (e.g. src/main/java-templates). Replace the version string with an
>> expression (e.g. "${project.version}") and use the copy-resources goal of
>> the resources plugin to filter the file into a target driectory tree
>> (e.g. target/generated-sources). Bind the goal to the generate-sources
>> phase. Then use additionally the build-helper plugin to add
>> target/generated-sources as additional source directory and you're done.
>
> Best solution was already mentoined by Robert Scholte by using the
> templating-maven-plugin which exactly supports that scenario without
> supplemental addition of target/generated-sources folder by
> build-helpr-maven-plugin etc.
>
> Just simply create the template files in src/main/java-templates/ use
> the expressions etc. no need for supplemental configuration of
> maven-resources-plugin etc.
>
> Best and simple solution...which i wrote longer time a go a blog about
> http://blog.soebes.de/blog/2014/01/02/version-information-into-your-appas-with-maven/
nice article ;-)
There's one comment I do not understand though:
> The main disadvantage of this approach is that you can only use the
> Implementation and Specification parts of your MANIFEST.MF file which
> might be enough in some situations but not in all.
You can add all kind of entries to the manifest. You may even overwrite the
defaults. We use typically:
===================== %< ======================
<archive>
<manifest>
<addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
</manifest>
<manifestEntries>
<Specification-Version>${parsedVersion.majorVersion}.
${parsedVersion.minorVersion}</Specification-Version>
<X-Compile-Source>${java.version.source}</X-Compile-Source>
<X-Compile-Target>${java.version.target}</X-Compile-Target>
<X-Builder>Maven ${maven.version}</X-Builder>
<X-Build-Time>${maven.build.timestamp}</X-Build-Time>
<X-Build-Os>${os.name}</X-Build-Os>
</manifestEntries>
</archive>
===================== %< ======================
With the $parsedVersion and $maven.version variables provided by the build-
helper plugin.
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: move data from pom to class or class to pom
Posted by Ron Wheeler <rw...@artifact-software.com>.
I have added a link to Karl's blog to my article.
On 17/07/2014 1:34 PM, Curtis Rueden wrote:
> Hi all,
>
>> Best and simple solution...which i wrote longer time a go a blog about
>>
> http://blog.soebes.de/blog/2014/01/02/version-information-into-your-appas-with-maven/
>
> I agree with Karl: I think it is much nicer to use the maven-jar-plugin to
> add the version to the JAR manifest, and just read it out of there, using
> the options:
>
> <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
> <addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
>
> That's not to say that code generation with Maven isn't awesome though.
> Codehaus deserves major kudos for the buildhelper-maven-plugin, especially
> since it is supported by M2E as well!
>
> In one my projects, we combine this with the groovy-maven-plugin and Apache
> Velocity to auto-generate many classes from templates in a loop.
> https://github.com/imagej/imagej-ops/blob/master/pom.xml#L190-L231
>
> I considered improving the velocity-maven-plugin [1] to support this sort
> of thing (reusing the same template to generate a list of classes), but the
> groovy approach is easy and works just fine.
>
> Now we just need an official Maven page about how to do this, since AFAICT
> all the existing blog posts and SO questions don't explain it very clearly.
>
> Great stuff,
> Curtis
>
> [1] https://code.google.com/p/velocity-maven-plugin/
>
>
> On Thu, Jul 17, 2014 at 10:18 AM, Karl Heinz Marbaise <kh...@gmx.de>
> wrote:
>
>> Hi,
>>
>>
>>> Move the Java code that should contain the version into an own directory
>>> tree (e.g. src/main/java-templates). Replace the version string with an
>>> expression (e.g. "${project.version}") and use the copy-resources goal of
>>> the resources plugin to filter the file into a target driectory tree (e.g.
>>> target/generated-sources). Bind the goal to the generate-sources phase.
>>> Then
>>> use additionally the build-helper plugin to add target/generated-sources
>>> as
>>> additional source directory and you're done.
>>>
>> Best solution was already mentoined by Robert Scholte by using the
>> templating-maven-plugin which exactly supports that scenario without
>> supplemental addition of target/generated-sources folder by
>> build-helpr-maven-plugin etc.
>>
>> Just simply create the template files in src/main/java-templates/ use the
>> expressions etc. no need for supplemental configuration of
>> maven-resources-plugin etc.
>>
>> Best and simple solution...which i wrote longer time a go a blog about
>> http://blog.soebes.de/blog/2014/01/02/version-information-into-your-appas-
>> with-maven/
>>
>> Kind regards
>> Karl-Heinz Marbaise
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: move data from pom to class or class to pom
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 17/07/2014 1:57 PM, Anders Hammar wrote:
> There is one major drawback with using the manifest file. It will not work
> with unit tests as the manifest file isn't created until the jar is
> created. But if your unit tests don't touch any of the code that reads the
> manifest info that's not a problem.
I have added this comment to my article.
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: move data from pom to class or class to pom
Posted by Anders Hammar <an...@hammar.net>.
> > Best and simple solution...which i wrote longer time a go a blog about
> >
>
> http://blog.soebes.de/blog/2014/01/02/version-information-into-your-appas-with-maven/
>
> I agree with Karl: I think it is much nicer to use the maven-jar-plugin to
> add the version to the JAR manifest, and just read it out of there, using
> the options:
>
> <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
> <addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
>
There is one major drawback with using the manifest file. It will not work
with unit tests as the manifest file isn't created until the jar is
created. But if your unit tests don't touch any of the code that reads the
manifest info that's not a problem.
/Anders
>
> That's not to say that code generation with Maven isn't awesome though.
> Codehaus deserves major kudos for the buildhelper-maven-plugin, especially
> since it is supported by M2E as well!
>
> In one my projects, we combine this with the groovy-maven-plugin and Apache
> Velocity to auto-generate many classes from templates in a loop.
> https://github.com/imagej/imagej-ops/blob/master/pom.xml#L190-L231
>
> I considered improving the velocity-maven-plugin [1] to support this sort
> of thing (reusing the same template to generate a list of classes), but the
> groovy approach is easy and works just fine.
>
> Now we just need an official Maven page about how to do this, since AFAICT
> all the existing blog posts and SO questions don't explain it very clearly.
>
> Great stuff,
> Curtis
>
> [1] https://code.google.com/p/velocity-maven-plugin/
>
>
> On Thu, Jul 17, 2014 at 10:18 AM, Karl Heinz Marbaise <kh...@gmx.de>
> wrote:
>
> > Hi,
> >
> >
> > > Move the Java code that should contain the version into an own
> directory
> >
> >> tree (e.g. src/main/java-templates). Replace the version string with an
> >> expression (e.g. "${project.version}") and use the copy-resources goal
> of
> >> the resources plugin to filter the file into a target driectory tree
> (e.g.
> >> target/generated-sources). Bind the goal to the generate-sources phase.
> >> Then
> >> use additionally the build-helper plugin to add target/generated-sources
> >> as
> >> additional source directory and you're done.
> >>
> >
> > Best solution was already mentoined by Robert Scholte by using the
> > templating-maven-plugin which exactly supports that scenario without
> > supplemental addition of target/generated-sources folder by
> > build-helpr-maven-plugin etc.
> >
> > Just simply create the template files in src/main/java-templates/ use the
> > expressions etc. no need for supplemental configuration of
> > maven-resources-plugin etc.
> >
> > Best and simple solution...which i wrote longer time a go a blog about
> >
> http://blog.soebes.de/blog/2014/01/02/version-information-into-your-appas-
> > with-maven/
> >
> > Kind regards
> > Karl-Heinz Marbaise
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
Re: move data from pom to class or class to pom
Posted by Curtis Rueden <ct...@wisc.edu>.
Hi all,
> Best and simple solution...which i wrote longer time a go a blog about
>
http://blog.soebes.de/blog/2014/01/02/version-information-into-your-appas-with-maven/
I agree with Karl: I think it is much nicer to use the maven-jar-plugin to
add the version to the JAR manifest, and just read it out of there, using
the options:
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
<addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
That's not to say that code generation with Maven isn't awesome though.
Codehaus deserves major kudos for the buildhelper-maven-plugin, especially
since it is supported by M2E as well!
In one my projects, we combine this with the groovy-maven-plugin and Apache
Velocity to auto-generate many classes from templates in a loop.
https://github.com/imagej/imagej-ops/blob/master/pom.xml#L190-L231
I considered improving the velocity-maven-plugin [1] to support this sort
of thing (reusing the same template to generate a list of classes), but the
groovy approach is easy and works just fine.
Now we just need an official Maven page about how to do this, since AFAICT
all the existing blog posts and SO questions don't explain it very clearly.
Great stuff,
Curtis
[1] https://code.google.com/p/velocity-maven-plugin/
On Thu, Jul 17, 2014 at 10:18 AM, Karl Heinz Marbaise <kh...@gmx.de>
wrote:
> Hi,
>
>
> > Move the Java code that should contain the version into an own directory
>
>> tree (e.g. src/main/java-templates). Replace the version string with an
>> expression (e.g. "${project.version}") and use the copy-resources goal of
>> the resources plugin to filter the file into a target driectory tree (e.g.
>> target/generated-sources). Bind the goal to the generate-sources phase.
>> Then
>> use additionally the build-helper plugin to add target/generated-sources
>> as
>> additional source directory and you're done.
>>
>
> Best solution was already mentoined by Robert Scholte by using the
> templating-maven-plugin which exactly supports that scenario without
> supplemental addition of target/generated-sources folder by
> build-helpr-maven-plugin etc.
>
> Just simply create the template files in src/main/java-templates/ use the
> expressions etc. no need for supplemental configuration of
> maven-resources-plugin etc.
>
> Best and simple solution...which i wrote longer time a go a blog about
> http://blog.soebes.de/blog/2014/01/02/version-information-into-your-appas-
> with-maven/
>
> Kind regards
> Karl-Heinz Marbaise
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: move data from pom to class or class to pom
Posted by Robert Scholte <rf...@apache.org>.
+1
Op Thu, 17 Jul 2014 17:18:38 +0200 schreef Karl Heinz Marbaise
<kh...@gmx.de>:
> Hi,
>
> > Move the Java code that should contain the version into an own
> directory
>> tree (e.g. src/main/java-templates). Replace the version string with an
>> expression (e.g. "${project.version}") and use the copy-resources goal
>> of
>> the resources plugin to filter the file into a target driectory tree
>> (e.g.
>> target/generated-sources). Bind the goal to the generate-sources phase.
>> Then
>> use additionally the build-helper plugin to add
>> target/generated-sources as
>> additional source directory and you're done.
>
> Best solution was already mentoined by Robert Scholte by using the
> templating-maven-plugin which exactly supports that scenario without
> supplemental addition of target/generated-sources folder by
> build-helpr-maven-plugin etc.
>
> Just simply create the template files in src/main/java-templates/ use
> the expressions etc. no need for supplemental configuration of
> maven-resources-plugin etc.
>
> Best and simple solution...which i wrote longer time a go a blog about
> http://blog.soebes.de/blog/2014/01/02/version-information-into-your-appas-with-maven/
>
> Kind regards
> Karl-Heinz Marbaise
>
> ---------------------------------------------------------------------
> 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: move data from pom to class or class to pom
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
> Move the Java code that should contain the version into an own directory
> tree (e.g. src/main/java-templates). Replace the version string with an
> expression (e.g. "${project.version}") and use the copy-resources goal of
> the resources plugin to filter the file into a target driectory tree (e.g.
> target/generated-sources). Bind the goal to the generate-sources phase. Then
> use additionally the build-helper plugin to add target/generated-sources as
> additional source directory and you're done.
Best solution was already mentoined by Robert Scholte by using the
templating-maven-plugin which exactly supports that scenario without
supplemental addition of target/generated-sources folder by
build-helpr-maven-plugin etc.
Just simply create the template files in src/main/java-templates/ use
the expressions etc. no need for supplemental configuration of
maven-resources-plugin etc.
Best and simple solution...which i wrote longer time a go a blog about
http://blog.soebes.de/blog/2014/01/02/version-information-into-your-appas-with-maven/
Kind regards
Karl-Heinz Marbaise
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: move data from pom to class or class to pom
Posted by Ron Wheeler <rw...@artifact-software.com>.
Jörg Schaible's response was so neat that I could not resist writing a
blog article about it.
http://blog.artifact-software.com/tech/?p=229 is the post.
If there are any comments about how to improve the article, I would
appreciate the feedback.
Ron
On 17/07/2014 5:03 AM, Jörg Schaible wrote:
> Hi Alejandro,
>
> Alejandro.Endo@miranda.com wrote:
>
>> Hi Curtis,
>>
>> I *think* i see you point, but wouldn't that happen ONLY if the constant
>> is public and referenced in a separate jar?? where it would be inlined in
>> the referring class (right?). In my case the constant is package protected
>> (it would be private if it wasn't because i need it in unit tests)
>>
>> The problem with defining it in the manifest is that I use this constant
>> in the property of an annotation of the class
>>
>> @StaticServiceProperty(mandatory = true, type = "java.lang.String", name =
>> "schemaVersion", value = SchemaProviderServiceImpl.SCHEMA_VERSION,
>> immutable = true)
>> public class SchemaProviderServiceImpl
>>
>> so I can't grab it from the manifest at runtime. I guess the way I phrased
>> it in the original email implied the opposite, sorry about that
>
> typical solution is to generate the source.
>
> Move the Java code that should contain the version into an own directory
> tree (e.g. src/main/java-templates). Replace the version string with an
> expression (e.g. "${project.version}") and use the copy-resources goal of
> the resources plugin to filter the file into a target driectory tree (e.g.
> target/generated-sources). Bind the goal to the generate-sources phase. Then
> use additionally the build-helper plugin to add target/generated-sources as
> additional source directory and you're done.
>
> Cheers,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: move data from pom to class or class to pom
Posted by Jörg Schaible <jo...@swisspost.com>.
Hi Alejandro,
Alejandro.Endo@miranda.com wrote:
> Hi Curtis,
>
> I *think* i see you point, but wouldn't that happen ONLY if the constant
> is public and referenced in a separate jar?? where it would be inlined in
> the referring class (right?). In my case the constant is package protected
> (it would be private if it wasn't because i need it in unit tests)
>
> The problem with defining it in the manifest is that I use this constant
> in the property of an annotation of the class
>
> @StaticServiceProperty(mandatory = true, type = "java.lang.String", name =
> "schemaVersion", value = SchemaProviderServiceImpl.SCHEMA_VERSION,
> immutable = true)
> public class SchemaProviderServiceImpl
>
> so I can't grab it from the manifest at runtime. I guess the way I phrased
> it in the original email implied the opposite, sorry about that
typical solution is to generate the source.
Move the Java code that should contain the version into an own directory
tree (e.g. src/main/java-templates). Replace the version string with an
expression (e.g. "${project.version}") and use the copy-resources goal of
the resources plugin to filter the file into a target driectory tree (e.g.
target/generated-sources). Bind the goal to the generate-sources phase. Then
use additionally the build-helper plugin to add target/generated-sources as
additional source directory and you're done.
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: move data from pom to class or class to pom
Posted by Al...@miranda.com.
Hi Curtis,
I *think* i see you point, but wouldn't that happen ONLY if the constant
is public and referenced in a separate jar?? where it would be inlined in
the referring class (right?). In my case the constant is package protected
(it would be private if it wasn't because i need it in unit tests)
The problem with defining it in the manifest is that I use this constant
in the property of an annotation of the class
@StaticServiceProperty(mandatory = true, type = "java.lang.String", name =
"schemaVersion", value = SchemaProviderServiceImpl.SCHEMA_VERSION,
immutable = true)
public class SchemaProviderServiceImpl
so I can't grab it from the manifest at runtime. I guess the way I phrased
it in the original email implied the opposite, sorry about that
Alejandro Endo | Software Designer/Concepteur de logiciels
From: Curtis Rueden <ct...@wisc.edu>
To: Maven Users List <us...@maven.apache.org>,
Date: 2014-07-16 14:27
Subject: Re: move data from pom to class or class to pom
Sent by: ctrueden.wisc@gmail.com
Hi Alejandro,
> I have a java class that has a constant in it (static final String).
> This string is a version number, e.g. "1.3.2-test".
Beware: the Java compiler often inlines constants, _including String
constants_, into classes that reference the value. So if you compile a
class "Foo" against version 1 of library "bar", then run with version 2 of
"bar" in the classpath, Foo will still see the constant value as 1 instead
of 2.
http://javasplitter.blogspot.com/2011/10/static-final-inline-trap.html
Much, much better to embed the version number into the JAR manifest,
and/or
read it out of the Maven POM which the maven-jar-plugin embeds in the JAR
file.
Regards,
Curtis
On Wed, Jul 16, 2014 at 1:18 PM, <Al...@miranda.com> wrote:
> I have a java class that has a constant in it (static final String).
This
> string is a version number, e.g. "1.3.2-test". I need to have this same
> value in a maven plugin configuration (the jaxb plugin) so I am
wondering,
> is it better to keep the actual declaration in the code and somehow tell
> maven to take it from the code, or is it better to declare it in the pom
> and tell java to take the literal value to define the constant from the
> pom??
>
> I don't know how to do either so I would also like to hear some ideas. I
> am hoping i don't have to use resource filtering since having a source
> file as a resource is kind of problematic to me. It has to be ONLY that
> file that gets filtered, it would need to be in a non-standard location
> not src/main/java (maybe this is not true), and in general, it seems to
me
> that treating source code as resource is counter-intuitive
>
> Has anyone else solved this issue with the DRY principle across
behaviour
> and build system?
>
> The short background is that maven generates an XML schema via jaxb and
> this schema file is then made available at runtime via a service
>
> Thank you,
>
> Alejandro Endo | Software Designer/Concepteur de logiciels
>
>
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
> Thank You.
>
DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.
Re: move data from pom to class or class to pom
Posted by Curtis Rueden <ct...@wisc.edu>.
Hi Alejandro,
> I have a java class that has a constant in it (static final String).
> This string is a version number, e.g. "1.3.2-test".
Beware: the Java compiler often inlines constants, _including String
constants_, into classes that reference the value. So if you compile a
class "Foo" against version 1 of library "bar", then run with version 2 of
"bar" in the classpath, Foo will still see the constant value as 1 instead
of 2.
http://javasplitter.blogspot.com/2011/10/static-final-inline-trap.html
Much, much better to embed the version number into the JAR manifest, and/or
read it out of the Maven POM which the maven-jar-plugin embeds in the JAR
file.
Regards,
Curtis
On Wed, Jul 16, 2014 at 1:18 PM, <Al...@miranda.com> wrote:
> I have a java class that has a constant in it (static final String). This
> string is a version number, e.g. "1.3.2-test". I need to have this same
> value in a maven plugin configuration (the jaxb plugin) so I am wondering,
> is it better to keep the actual declaration in the code and somehow tell
> maven to take it from the code, or is it better to declare it in the pom
> and tell java to take the literal value to define the constant from the
> pom??
>
> I don't know how to do either so I would also like to hear some ideas. I
> am hoping i don't have to use resource filtering since having a source
> file as a resource is kind of problematic to me. It has to be ONLY that
> file that gets filtered, it would need to be in a non-standard location
> not src/main/java (maybe this is not true), and in general, it seems to me
> that treating source code as resource is counter-intuitive
>
> Has anyone else solved this issue with the DRY principle across behaviour
> and build system?
>
> The short background is that maven generates an XML schema via jaxb and
> this schema file is then made available at runtime via a service
>
> Thank you,
>
> Alejandro Endo | Software Designer/Concepteur de logiciels
>
>
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
> Thank You.
>