Hi Roy,
that's a useful addition. Indeed I do something similar with with some
command-line tools. I ship them as a zip which contains: a .jar a
.sh/.bat invoking commands and a default .properties file. For the
latter, I want different defaults depending on the environment where I
deploy final zip. I could just ask the users to point to the right
.properties file, but the fact is that we have the dev/test/production
environments and in the first two we want a situation that is as close
as possible to the third.
Thanks anyway.
Marco.
On 21/09/2012 01:32, Lyons, Roy wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
