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, <[email protected]> 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 <[email protected]> > To: Maven Users List <[email protected]>, > Date: 2014-07-16 14:27 > Subject: Re: move data from pom to class or class to pom > Sent by: [email protected] > > > > 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, <[email protected]> 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. >
