maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alejandro.E...@miranda.com
Subject Re: move data from pom to class or class to pom
Date Wed, 16 Jul 2014 18:43:35 GMT
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 <ctrueden@wisc.edu>
To:     Maven Users List <users@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, <Alejandro.Endo@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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message