Re: What is the Best practice for generating variations of an artifacts?

[Vincent Massol <vi...@massol.net>]

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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org