[m2] Multiple ear generation

[Trevor Torrez <ja...@gmail.com>]

I need a way to load an arbitrary number of the same application EAR
to a single websphere instance.  The reason behind this is that during
the test phases of software development several testers need to run
the application cuncurrently without stepping on each other's toes.
However, if an attempt is made to deploy the same application to
websphere more than once, websphere rejects the duplicate application
(probably with good reason ;) ).

I'm looking for a best-practice kinda guideline to solve this problem.
 Ideally I would like to be able to run a single command to generate
all the necessary EARs with the application.xml file modified as
necessary to prevent websphere from rejecting the duplicate
applications.  A few of the ideas I have are:
1. Creating a separate profile for each test "environment"
    - The problem with this is that if an additional tester gets added
to the team a wait cycle is introduced as the pom needs to be updated
and the entire project pushed through the build cycle, not to mention
the duplication and needless proliferations of nearly identical files
and profiles information.
2. Creating a single separate profile for the test build which uses a
supplied parameter/property to perform the necessary replacements in
the application.xml file
    - The problem I see with this is that the test application.xml
file may diverge from the production file, and profile properties do
not override default properties, and command line properties are
ignored if the property is specified in the pom / profile.
3. Create a script (probably ant) to generate the production EAR, and
for each tester profile, unpack the ear, modify whatever, and repack
as a different name.
4. Create a maven profile to do the above
    - Is this even possible as a single maven profile?  Is it possible
to run one maven command and perform the same build but using an
arbitrary number of conflicting profiles to generate different
artifacts?

Number 4 would probably be the most ideal, but I'll settle for a
standard way of doing number 2 or 3.

thanks;

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org