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]
