Vincent Massol wrote:
I personally use two different approaches for customizing environmental settings of produced artifacts:I agree that putting <filtering> in the POM is a good first approach but that it won't handle the need for different environments.
This is something that I've been wanted to include in maven for a very long time: the ability to say "build me this project for this environment".
It seems that you're currently moving in the direction of doing this with the settings.xml file. However I'm concerned that the definition of the different environments is something that you need to share with your co-workers so it can't be located in a file that contains machine-dependent information such as (location of your local repo, etc). In other words parts of the environment definition should be shared through the SCM and part shouldn't.
I was going to propose a solution but I've just realized while writing it
that it needs more thinking... :-)
/
/1. Source based approach
I share the same sources between multiple projects. For example I use the organization of the projects which resembles this one:
- template-project
src
main
resources
conf
db.conf
a.xml
- envs
envA (point to resources defined in template-project and adds some new resources)
src
main
resources
conf
b.xml
filters (this is used for "resource filtering")
some-propertiesA.properties
some-propertiesB.properties
envB
...
project.xml in envA node among others has the following entry:
<resources>
<resource>
<filtering>true</filtering>
<directory>../../template-project/src/main/resources</directory>
</resource>
<resource>
<directory>src/main/resources</directory>
</resource>
</resources>
2. binaries based approach
If I need to customize some environment specific settings in existing artifacts (binaries) I do the following:
a) unpack them
b) replace some files with new ones
c) sometimes I apply resource filtering
d) create new archive
So for example I unpack existing war archive, replace web.xml file and then create another war file.
In this case I can also customize existing 3rd party artifacts. To my surprise this approach works quite fast in practice.
What's nice in case of those both approaches (they can be applied in the same project)
then I can always choose for which env. I want to build an artifact (no command line switches are needed!)
and I can use continuous integration system for building artifacts for each of the defined environments.
So maven key rule - one project one artifact is obeyed.
I hope that this will be helpful for /accommodating different use case.../
Michal
------------------------------------------------------------------
Teraz na tapecie mamy najwiekszego z silaczy. Sciagnij >> http://link.interia.pl/f1873 <<
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
