OK, I understand that in general it should be considered an
anti-pattern. Despite that, in my organisation we deploy a number of
internal tools on a couple of servers and with different configurations
(dev, test, production). To achieve this we do what it was originally
asked in this thread.
I think the only way for that with the assistance of Maven is how it was
suggested: use property files with ${placeholders} and tell Maven to
resolve them, then define the corresponding properties in the profiles.
This is an example:
http://github.com/EBIBioSamples/core_model/blob/master/pom.xml
Note that the <resource> and <testResource> sections have:
<filtering>true</filtering> and then there are parametrised files like:
http://github.com/EBIBioSamples/core_model/blob/master/src/test/resources/hibernate.properties
In this particular module, things are set only to change the
configuration that JUnit tests receive, but the trick works the same way
if you have another property file in src/main/resources. Yes, it makes
the final jar dependent on Maven profiles and on a particular
environment, however it may be acceptable in certain situations (like ours).
Marco.
On 20/09/2012 21:16, Ron Wheeler wrote:
Maven is not the place to set run-time information.
Trying to use profiles in this way, will only lead you to heartache
and a dislike of Maven.
http://blog.artifact-software.com/tech/?p=150
http://blog.artifact-software.com/tech/?p=58
Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
