Hi Jeff,
On Mar 16, 2007, at 1:00 PM, Jeff Jensen wrote:
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.
You're just moving the problem elsewhere! :)
You'll still need to configure those datasources in your container
config file.
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.
I don't like this approach too much as:
1) the app becomes bloated. For example it means adding the MySQL +
HSQL DB + Oracle + PostGreSQL driver jars.... It starts to add up...
2) it's not as nice for the end user as you need to explain to him
that he needs to set some env variable, etc, whereas in the approach
where you make the different distributions available, he just picks
the one he wants and it works out of the box
Thanks for your inputs!
-Vincent
-----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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
