maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curtis Rueden <ctrue...@wisc.edu>
Subject Re: move data from pom to class or class to pom
Date Wed, 16 Jul 2014 18:46:50 GMT
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, <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
>
> 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