Thanks for the tips Wayne and Anders.
I think I have two main options:
1. Use mvn -s with a settings.xml for each config I need. I didn't
know this option existed, so thanks for the pointer Wayne. This lets
me basically treat my settings.xml as my profiles.xml file.
2. Modify our build to work like Anders suggests.
I will probably go with option 1 for now and consider option 2 in the
future. I am however, not sold on the paradigm of building a web
application once and committing it to a central repo. Our web
applications are in general deployed once, so the need to get the
artifact from a central repo over and over again pretty much doesn't
exist. In general I really believe in the maven way for things that
can be dependencies of other things. But, a web app is almost never
a dependency of another project, so adding it in to the maven repo
doesn't really do much.
Furthermore, we have 5 tiers (ci, dev, qa, demo, prod) per client.
Each client has a set of configuration options and each tier needs its
own specific configuration information (database connections, remote
service url's, etc). So the number of total classifiers, or overlay
projects, would need to be 5 X number of clients. Then you have to
add in to the confusion that our integration / selenium tests need to
run on the final configured artifact. Right now those tests live in
the module that builds the ear. This is natural and allows the built
artifact to be tested from the project that builds it. Moving the
final configuration out to some overlay project would make testing
less natural.
On a side note, if anyone knows why the profiles.xml file support was
removed, I would be curious to know the reason. Local build
properties are pretty common, and in general putting them in a common
settings.xml file for all of the maven projects on your computer seems
weird. Take the case where I have two projects that need to know
where the local app server you are deploying to exists. If both use
the same property (jboss.home or tomcat.home, or something like that),
but need to go to different versions of the app server, you have to
constantly edit your settings.xml to point to the correct global
jboss.home, or always remember to build with a -P<correct_profile>.
One build's property configurations shouldn't have to be put in a
global file. Local build properties are just a good feature for a
build system independent of my personal issue on our build machine.
And to end on a positive note, I do like how much faster maven 3 is
for my builds. The few I have migrated are all 20% or so faster.
Thanks again for all the help,
Scott
On Nov 10, 2010, at 11:29 PM, Anders Hammar wrote:
..or my favorite:
Change to the Maven Way(tm)! What you're doing is not, IMHO, the
correct
way. I guess you're not doing Maven deploys to a remote repo as you
would
end up with different flavors of a project's artifact? Which can't
happen as
releases mustn't change.
What you should do is to either separate each customer build with a
classifier (one project for all customers) or one project for each
customer.
In the latter case you would build the "standard" artifact in one
project
and then do some kind of overlay in the Maven projects producing the
customer artifacts.
/Anders
On Thu, Nov 11, 2010 at 07:56, Wayne Fay <[email protected]> wrote:
and copy them in as part of the hudson build. I guess we could
put the
settings.xml file for the hudson user in to source control, but
having
all
of that information from across all of our projects in one place
is far
from
Well, it seems like you have a few options...
1. One big settings.xml file
2. Lots of settings.xml files and use -s parameter to mvn to pick the
right one to use
3. Move all profiles to various pom.xml files
4. Merge or rewrite the old code so Maven3 works with profiles.xml
files
5. Stick with Maven2 indefinitely
There are probably other options I haven't considered as well.
Wayne
---------------------------------------------------------------------
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]
