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

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

Good summary of the different options Franz!

For the moment I'm happy with the solution I have found but I may  
revisit it in the future, who knows.

For those interested here's a working example:
svn checkout svn://svn.forge.objectweb.org/svnroot/xwiki/xwiki/trunk/web

Check the web/standard/pom.xml file and the web/exo/pom.xml one.

-Vincent

On Apr 23, 2007, at 2:09 AM, franz see wrote:

>
> Good day,
>
> What remote resources plugin does is that it extracts the resources  
> from a
> specified artifact, into ${basedir}/target/maven-shared-archive- 
> resources.
> And add those resources to your build's list of resources.
>
> * [Filtering of remote resources]: Yes, it is possible to do so. It  
> uses
> velocity for its filtering ( see [1] )
>
> * [Need for a "common stuff" module]: Yes, but I don't see any  
> problems with
> this. All you're doing is transferring all your common stuffs to  
> another
> module so that others may be able to reuse them....Just like  
> extracting a
> class :-)
>
> * [A LOT of build modules]: Yes, but the alternative is one big maven
> project with LOTS of profiles.
>
> * [More Complex Build]: Yes, in a way it is since remote resources is
> relatively new and more people are more familiar with profiles than  
> the
> remote resources plugin. But IMHO, it's not that hard to understand.
> Furthermore, although you will end up with quite a number of  
> modules, at
> least your single project ( especially your pom ) will not be  
> gigantic.
>
> * [Number of Variations]: Instead of defining a variation in a  
> profile,
> define it as a resource module. Then instead of doing a mvn install
> -Pmysql,tomcat,cluster, you will now have a maven project that will  
> retrieve
> the remote resource from your mysql-resources, tomcat-resources, and
> cluster-resources.
>
> Main Differences
>
> * [Do you need more than one variation at a time?] If in the end,  
> you only
> want to produce one artifact variation, then profiles would be  
> sufficient.
> But if you need to produce more than one artifact variation, then I  
> suggest
> you use this approach.
>
> * [What do you prefer - one huge project, or several small  
> projects?] If you
> use the profiles approach, the more variations you add up, the  
> bigger your
> project becomes. However, if you use the remote resource approach,  
> the more
> variations you add up, the more modules you will have. As to which  
> one is
> better - I am not really sure :-) Probably, it's just a matter of
> preference.
>
> Regarding the better approach?
> hmm....ok, maybe this is not the "better" approach :-) This is  
> actually just
> an alternative that I prefer. With this approach, you'd be able to  
> build one
> variation, or if the need arises, several variations ( although you  
> can do
> that as well with profiles + CI, AFAIK, you'd only be able to  
> deploy only
> one variation ). Moreover, I prefer several small projects than a  
> single big
> one :-)
>
> Cheers,
> Franz
>
> [1]
> http://maven.apache.org/plugins/maven-remote-resources-plugin/ 
> process-mojo.html#properties
>
>
> vmassol wrote:
>>
>> 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: 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
>>
>>
>>
>
> -- 
> View this message in context: http://www.nabble.com/What-is-the- 
> Best-practice-for-generating-variations-of-an-artifacts-- 
> tf3414040s177.html#a10129217
> 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