Hi,
Vincent Massol wrote:
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.
You could use the buildhelper-maven-plugin or the assembly plugin
to attach the artifact with a classifier.
You can also configure the jar/war plugins with a <classifier> element.
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.
That's not an option. The pom is shared between all artifacts,
both primary and all secondary attachments. The main artifact is always
without 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?
This is typically solved in several different ways, depending on the role
a person has in the team. Standard j2ee practices etc. recommend a 'deployment
manager'
to either edit WEB-INF/web.xml before deploying, or as an alternative, a
'system manager' will provide you with the name of a JNDI Datasource configured
in tomcat's server.xml (or whatever container is used).
This latter approach is best since it won't require any modifications to the war.
In the case of embedded databases or other circumstances, some other solutions
could
be:
- split the configuration into 2 files: the common file that's the same for
each 'classifier',
and a database/environment specific file. The modules would then only contain
the environment specific file
- create the environment specific file using filtering and maven's profile
mechanism
- package up just 1 war with a property file for all possible environments.
Specify a system property or a configuration file or JNDI property that
contains the name
of the type of environment, and let the webapp load the appropriate property
file.
Downside is that you cannot use the automatic mechanism of the db provider to
load the property
file, but you have to supply it in code.
I'd go with either profiles for different environments, or just use settings.xml
with some properties that need to be configured (so that developers themselves
can choose wheter 1 profile is sufficient, or create multiple profiles for
different
environments).
If the only data you want to change is database settings, I'd go with a static
JNDI name.
HTH,
-- Kenney
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]
