I have looked into several options.
Assembly with Qualifiers (new module):
Looks good because I can run multiple <executions>, each with a unique
<filter>somefile.property</filter>. However I can't re-use the same
assembly description because the classifier is now obatined from the <id>
in the assembly descriptor :'( . That kinda sucks, it means I would have to
duplicate the assembly xml for each target classified artifact (or
copy/filter/rename the assembly xml during a gererate-sources or similar).
IMHO, this is not the best solution.
Profiles:
Only allow one build property set to exist, and thus each build can't use
filtering on the config. For this reason the resulting duplication and
deviation on each build would introduce bloat and increase the likelyhood
of breakage.
War Overlays :
This is (unfortunately) the best solution I have.
+acme (pom)
++acme-webapp (war) <--- all config options remain as ${someProperty} (ie.
No Filtering here!)
++acme-webapp-overlay (pom)
++acme-webapp-overlay-dev (war)
++acme-webapp-overlay-uat (war)
++acme-webapp-overlay-prod (war)
The acme-webapp-overlay will configure the
<plugin>...<artifactId>maven-war-plugin</artifactId><overlays>... (as well
as configure a dependecy too acme-webapp) the and each child module
(dev,uat,prod) provides their <properties>, which will filter selected
parts of acme-webapp (war) as it is overlayed.
This works, but I'm over it :)~
Thanks for all the advice
On Thu, Apr 19, 2012 at 2:38 AM, Wayne Fay <wayne...@gmail.com> wrote:
> > I will read up some more. But, I was more wondering in regards to
> > classifiers if I could release x3 (or more) builds of the same module (at
> > the moment I have one module per conf, each is a war overlay).
>
> I am not a huge fan of producing multiple artifacts (thus, your
> suggestion of classifiers) for these types of purposes.
>
> Instead, you should think about what kinds of things you could do that
> would allow to produce a single artifact and then push it unchanged
> into your various deployment environments. There are lots of
> strategies to help with this problem: JNDI, Spring, other DI
> solutions, etc.
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
