G'Day,
I've just come across this thread. This is a problem that I too have
been wrestling with for the last few months, particularly with
respect to producing target environment (sit, uat, prod) dependent
artifacts.
I tend to agree with one of the respondents in that it is best to
push as much environment specific stuff as possible off to the
application server. However, I find myself remedying other peoples
code quite a bit, and a lot of it has property files scattered all
over the shop. I find mail server configuration is the number 1 culprit.
My solution has been to use profile driven classifiers (I instigated
the addition of classifier support to the ejb plugin).
This works pretty well, except when running the release plugin, where
something sensible must be generated in the absence of a specified
profile. Of course, while writing this note I realised that it has
not occurred to me to try and set the profiles up so that can be
executed altogether. Or to try multiple executions of the ejb/war/
ear plugins.
The other problem with using profiles like this is that the poms
become very verbose, and the DRY principle gets completely blown out
of the water.
This is one area that maven does not handle as elegantly as most of
the other problems it solves.
Cheers,
Steve Coy
On 23/04/2007, at 10: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: [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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
