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: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
