I do my best to avoid needing a separate build per environment. A release
is a release, and while reproducibility is not the issue, I find it silly to
do so.
In my customer work, I found two key strategies that have worked well, both
from "new system" and streamlining an existing system:
Option 3
--------
Use container configuration. Just get the DataSource for a connection. For
other info, set properties and/or servlet context params.
Option 4
--------
Include all property files in the artifact, and the environment determines
which one is used:
- Have a base name for the set of property files, e.g. app.properties.
- Set an environment variable on each runtime environment, e.g.
APP_ENV=dev, APP_ENV=test, APP_ENV=prod.
- Have the code load props from app_${APP_ENV}.properties. Or use the env
var as a directory name for a collection of env specific files, e.g.
${APP_ENV}/app.properties.
-----Original Message-----
From: Vincent Massol [mailto:[EMAIL PROTECTED]
Sent: Friday, March 16, 2007 6:39 AM
To: Maven Users List
Subject: What is the Best practice for generating variations of an
artifacts?
Hi,
I've never found a good answer to this use case so far so I'm curious about
how others have implemented it.
Imagine a project that generates a WAR. This WAR contains a config file (say
in WEB-INF/classes) that configures connection parameters for the database.
Now imagine that your project wants to support several databases and you
want the ability to build for a given database.
I see 2 options:
Option 1
-----------
* Use filtering
* Use profiles to set the values for the different databases
Issues:
* In order to differentiate the generate WAR file name you'll need to use
<finalName> but the value set there won't be used for install/ deploy which
means that the WAR files users will see will always be the same.
Idea for future:
* It would be nice if Maven had a <classifier> element under <project> so
that it would be possible to generate an artifact with a classifier.
Option 2
-----------
* Create one module per database, under a parent module
* Create profiles in the parent module to conditionally include the <module>
to be built
Issues:
* Very heavy (one module per database) especially when the only difference
between the generated artifacts is only 3 lines in a config file
* Need a way to share common configuration between the modules, in order to
prevent duplication. For example if the config files only contains 3 lines
that are different for each database and there are 100 lines in total, you
don't want to duplicate the 97 lines in as many modules as you have
databases
What do people do? Is there some plan to support this use case in a better
fashion in the future?
Thanks
-Vincent
---------------------------------------------------------------------
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]
