To avoid having to build an artifact per environment we took the
approach of having a single build which contains all properties for all
environments, but we use a runtime flag to tell the application which
set of properties to use. So inside the war (or whatever packaging you
use) we have a directory structure something like this,
properties/environment1/foo.properties
properties/environment2/foo.properties
properties/environment3/foo.properties
properties/environment4/foo.properties
properties/environment5/foo.properties
properties/common.properties
and then pass a -Denvironment=environment3 at startup which instructs
our app to use the foo.properties from the environment3 directory. I'm
not sure what technology you are using but we use spring which makes
this type of configuration very easy. We took this approach for
different reasons but it does save all the messing around with either
builds per environment or filtering at deploy time.
Cheers
Matt
On 24/11/09 08:37, John Prystash wrote:
Before Maven, we used Ant. The build output was a tar.gz that was staged to the
install host. A deploy consisted of an unpacking of the .tar.gz and Ant was
run given a properties file and an installation directory.
With Maven, our current process is to filter for the target environment at
build time, producing an application inside .tar.gz that can be unpacked and
started, but that requires one build per environment.
________________________________
From: Anders Hammar<[email protected]>
To: Maven Users List<[email protected]>
Sent: Mon, November 23, 2009 4:06:11 PM
Subject: Re: Thoughts on build vs deploy time property filtering
Well, I would argue that you should keep all environment specific
configuration outside of your "artifact".
How can you do filtering on deploy? Do you explode your jar/war/ear, filter,
and then repack?
/Anders
On Mon, Nov 23, 2009 at 16:59, John Prystash<[email protected]> wrote:
Hi, I was hoping for some thoughts from the community about the reasons
behind why one might want to filter at build time versus at deploy time.
Traditionally, our organization built one artifact from version control
that still contained property placeholders. We would filter those artifacts
at deploy time, so that the artifact was completed as it deployed to the
target environment. This was seen as beneficial as we only had to build our
artifact once, and then we can deploy that same artifact multiple times.
It appears as though maven prefers to filter at build time, and create a
different artifact per environment. What are the benefits of this
methodology? It looks like you would have to do multiple builds (to produce
an environment-specific artifact), where before, we could only build a
filterable artifact once.
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
