Hi John and everyone,
Sorry for answering you so late on this and thanks again for your
feedback.
Following your direction I think I've found something slightly better:
* I use a pom packaging
* I use the assembly plugin to directly generate a WAR using the
following assembly descriptor:
<assembly>
<id>${xwiki.db}</id>
<formats>
<format>war</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<dependencySets>
<dependencySet>
<outputDirectory>WEB-INF/lib</outputDirectory>
</dependencySet>
</dependencySets>
<fileSets>
<fileSet>
<directory>${basedir}/src/main/webapp</directory>
<outputDirectory>/</outputDirectory>
</fileSet>
</fileSets>
<files>
<file>
<source>${basedir}/src/main/resources/hibernate.cfg.xml</source>
<outputDirectory>WEB-INF/</outputDirectory>
<filtered>true</filtered>
</file>
</files>
</assembly>
* ${xwiki.db} is defined in the pom.xml in each profile
* hibernate.cfg.xml contains properties defined in each profile. I
could also use a filter file but it's not necessary in this example
I'm currently happy with this solution (need to test further though
as I've just tried it and was excited to have found something that
seems to work) except that I find it strange to have to declare my
packaging to be pom when all I want to generate is a war...
I'll post back when I have finished implementing and testing this
solution.
Thanks
-Vincent
On Mar 16, 2007, at 8:19 PM, John J. Franey wrote:
I came up with a third path. Mutliple projects, but with a slight
difference.
In the base project, an assembly would create an archive of unfiltered
configuration files. So the base project has the war (or jar) and
a zip of
unfiltered configuration files. This project does not put any app
server
specific configuration files in its output.
In the assembly projects, use dependency plugin to unpack the
unfiltered
configuration files from the base project. Use assembly plugin to
reassemble, filter (too bad assembly-plugin doesn't support FileSet
filtering in 2.2-SNAPSHOT today). Mixin app server specific
configuration
files.
I put a filtered property in the assembly id to distinguish
archives built
with different profiles. The assembly plugin uses the assembly id
in the
name of the archives.
Drive multiple builds of the same assembly project for each set of
profiles
you define. At the end, target contains an archive for each
unique use of
the assembly Id property. This is done manually or with a shell
script.
Maybe this is the core issue you are addressing. I didn't think
maven did
any iteration like this.
The advantages of this approach:
App server specific configuration details (e.g. tomcat
context.xml) are
isolated from common j2ee configuration (web.xml). The base
project is not
laden with server specific configuration details. Unit level
developer is
can tweak his runtime more freely.
Disadvantge:
The configurable properties set in the base project must be
propagated up to
the assembly projects so that they are correctly set. This is a
nuisance.
John
--
View this message in context: http://www.nabble.com/What-is-the-
Best-practice-for-generating-variations-of-an-artifacts--
tf3414040s177.html#a9520819
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
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]
