I would like to say that there is definitely a better way. You *could*
continue to use maven for filtering your properties, but I wouldn't use it
as part of the build of the application.
If you are simply using scp or other similarly crude method of deployment
(meaning you are just deploying as a file transfer), I would say that you
could set up a maven project on the server side which handle the
deployment. You can setup a pom.xml with all of the maven objects as
dependencies (including your jar/war/ear files you already built) and then
use the assembly plugin to create a staged application environment
including a variable replacement on template-ized external property files
which your application can reference (the replacement being done by
filtering within assembly directives). As a matter of fact, I would argue
that this could be all stuffed in a git repository and your installation
could be done with:
ssh $servername "git clone -b $branchname $gitprojecturl \; cd
$targetdir
\; mvn -P $envname dependency:resolve assembly:assembly \; $startscript"
Or
ssh $servername "cd $targetdir \; $stopscript \; git clean -f \; git
pull
origin \; mvn -P $envname dependency:resolve assembly:assembly \;
$startscript"
Long and short is that it is still possible to do what you want with
maven, but not inside of the box you are thinking in. As a configuration
engineer, I know that environment specific properties (and usually other
properties too) should always be stored in files external to your jar.
"The Maven Way" will tell you to make re-usable stuff. Your deployment
artifacts are no exception. Don't force a rebuild when a property has to
change. Your QA folks will be extra thankful since the jar/war/ear will
maintain a constant md5sum that they can use to justify not performing
full regression tests.
Disclaimer: We are using a highly sophisticated and expensive tool for
deployments and can't use this method due to auditing needs. However we
still have our tool perform a post-process interpolation of variables
within config files based on environment to achieve a similar end result.
Also, to prevent a flame-war -- I am presenting this as a feasible
alternative way to use maven for the purpose of filtering properties based
on a profile being set (the original poster's intention) that will perhaps
help the original poster think outside of the box to achieve their goals.
Thanks,
Roy
On 9/20/12 4:48 PM, "Zak Mc Kracken" <[email protected]> wrote:
>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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
