Something like that. Based on some rules, we actually bind it onto
different subpart of the version string.
2013/1/16 Jörg Schaible <joerg.schai...@gmx.de>
> Hi Baptiste,
>
> Baptiste MATHUS wrote:
>
> > Hi all,
> >
> > Note: I know the standard approach to this subject: filtering a
> > .properties file and reading it.
> > But this does not work when you actually want to use the value inside an
> > annotation attribute (needs to be a real constant).
> >
> > We actually bind our EJB on specific JNDI URL by doing something like:
> >
> > @Stateless
> > @EJB(name = "java:global/someejb-${project.version}")
> > public class SomeEJB31 { ... }
> >
> > Does someone have an idea on how to solve this cleanly?
> >
> > We already have a running solution using a dark magical combination of
> > antrun/build-helper manipulations, but this gives us a complicated pom to
> > maintain and moreover M2E doesn't like it at all.
>
> What are you up to? Do you really want to address you EJBs with "java-
> gobal/someejb-2.3.12-SNAPSHOT"? Or is it more like "java-gobal/someejb-2.3"
> , i.e. a "major.minor" pattern?
>
> If it is the latter, you might simply use "sed" and a regular expression to
> update the files from command line every time you update a major/minor
> version and ensure with the verifier plugin, that no java file contains an
> @EJB line that does not contain current major.minor.
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
