Hi Franz,
On Apr 20, 2007, at 4:50 AM, franz see wrote:
Good day,
If the only thing different with the variations are the config
files and
some dependencies, then I suggest you use #2.
Thanks for your help. How is #2 better than the solution I'm now
using (which used the assembly plugin to generate the WAR with the
proper files and dependencies)?
It seems to me solution #2 has the following cons:
* It's more complex in term of build and requires more effort,
maintenance and require more effort to explain.
* There's a need for having a module for common stuff.
* How do you share a common configuration (say a properties file)
that only differs in some properties? In the latest solution I've
found I simply use Maven properties or filter files. Does the remote
resources plug in allow filtering of files when they're copied? If so
that solves this issue.
* Solution #2 doesn't scale with the number of variations. Imagine
that variations are a combination of: database configurations, app
server configuration, some other configuration. Imagine that we want
to support 4 databases, 5 containers and 2 variation of the "other"
configuration. that's a LOT of variations and would mean a lot of
build modules, whereas with my current solution it's very simple and
only requires one profile for each database, one profile for each
appserver and one profile for the "other" type of configuration. Then
it's up to the user to pick the profiles he wants to use. For
example: "mvn clean install -Pmysql,tomcat,cluster".
The advantage of solution #2 would be to generate all variations in
one build rather than running several times the same build with a
different profile. As this would be time consuming, we'd need
profiles anyway for normal use and for CI use (where we'd want
everything generated). This is the main difference I can see.
Anything I'm missing? :)
Thanks again for this interesting discussion
-Vincent
With regards to the shared
resources, you can do that now with the maven-remote-resources-
plugin. So
you now have something like...
.
|-- core
`-- variations
|-- variation-a
|-- variation-b
|-- variation-c
:
`-- variation-z
wherein your core has the common resource as well. Then you just
bundle up
core, and process it in the variation-<xxx>.
Cheers,
Franz
vmassol 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.
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]
