maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anders Hammar <and...@hammar.net>
Subject Re: how to centralize configuration accross multiple modules
Date Tue, 05 Oct 2010 19:39:00 GMT
I want to second Wayne here and stress that doing different builds for each
environment is NOT the Maven way. I want to stress this as I very often run
into this solution which people have grown used to it and it make it very
hard to set up correct Maven environments with a repository. It is an
anti-pattern when using Maven - there can be just one flavor of an artifact
for a specific version.

Sure, you could solve it by using classifiers and create several artifacts
for each project. But it is so much better to separate the binary and the
configuration. However, I understand that it can sometimes be tricky. Most
of your reqs can be accomplished by just reading the config from a
properties file. You read the properties file from the classpath and then
just make sure the properties file is on the classpath in runtime. I'm sure
all containers have a way to do that keeping the file outside of the
deployable. I mostly use JBoss and there you put it in the conf folder.

Regarding the fact that these config values change, it makes even more sense
keeping them outside of the build. So when a db connection string changes,
you don't have to roll a new build (which MUST be a new version in the Maven
world).

/Anders
On Tue, Oct 5, 2010 at 20:08, Jon Paynter <kittle31@gmail.com> wrote:

> well it was a suggestion - do what you will with it.
>
> But how would you implement this using the maven way?
>
> given the following restrictions/requirements:
> each environment has its own hostname and number of hosts (dev 1 host, qa 4
> hosts, prod 8 hosts)
> each environment has a different db connection string
> each environment has its own set of passwords for accounts (db, unix, and
> tibco)
> each environment has its own set of port numbers fo the various processes.
> each environemnt has its own set of webservice urls.
> and all of our j2ee processes have other application specific config values
>
> Add to that, most of the config values change frequently as things evolve
> and change.  we found its much easier to put all these values into a single
> file,  edit one file, and run a build.  Granted this was with a morass of
> ant scripts, but given the volume of changes, the .properties files worked
> quite well.
>
> On Tue, Oct 5, 2010 at 10:27 AM, Wayne Fay <waynefay@gmail.com> wrote:
>
> > > For property values -- I setup a .properties file for each of our
> > > environments with the default being 'dev'.  So for a default build, the
> > dev
> > > properties are used.  but when its time to build for QA or Production,
> > you
> > > add a cmd line argument accordingly:   mvn install -DenvType=QA
> >
> > IMO this is an anti-pattern for Maven usage. You should be able to
> > build one single artifact in say Dev and then promote that same
> > untouched/changed artifact through your various environments.
> > Otherwise the artifact that gets QA'ed is not the same artifact that
> > lands in Production... which defeats the purpose of QA.
> >
> > You should generally deal with these variances in the environments via
> > JNDI or other mechanisms available in the platform (JavaSE/JEE or
> > whatever container you're deploying into).
> >
> > Wayne
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message