Jared,

I think the best practice in this area is to configure the deployment
environment (i.e. app server) and not the deployable (WAR, EAR,...). It
prevents potential failures that could be introduced if you change a
known-good deployable, or forget to change when you "graduate" the
deployable to production.

If you search the archives, you'll find similar suggestions.

I've run into resistance to this idea on some projects, and I've seen those
same projects deploy test WARs into production, and vice versa. I've even
been the one doing the deploy. The common complaint I've heard is a lack of
flexibility (...but I want my test app to talk to the production DB
because...).

If you've already externalized your various configurations such that they
can be scripted like you describe, then you've done most of the work.
Property files and/or JNDI are your friend here, most app servers make this
kind of stuff fairly easy.

Good Luck!

On Fri, Aug 3, 2012 at 10:55 AM, Matt Walsh
<mwa...@chartwelltechnology.com>wrote:

> Can you not do this using filtered overlays in the maven-war-plugin.
> Build a "generic" war, then have other war projects dependent on the
> generic war as an overlay and apply property filters to it.
>
> So you'd have one generic-war project, built in the usual way, with no
> property filters. Then one or more configured war projects with a
> dependency on the generic war. In those projects, configure the war
> plugin like so.
>
> <plugin>
>    <artifactId>maven-war-plugin</artifactid>
>    <configuration>
>      <overlays>
>        <overlay>
>              <groupId>your.group</groupId>
>              <artifactId>generic-war</artifactId>
>              <type>war</type>
>              <includes>
>                   <include>file to be filtered</include>
>                   <include>file to be filtered</include>
>                  ....
>            </includes>
>            <filtered>true</filtered>
>         </overlay>
>       <overlay>
>              <groupId>your.group</groupId>
>              <artifactId>generic-war</artifactId>
>              <type>war</type>
>         </overlay>
>
> Two overlays cause you probably don't want to be filtering binary files.
>
> Matt
>
> > -----Original Message-----
> > From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
> > Sent: Friday, August 03, 2012 10:16 AM
> > To: users@maven.apache.org
> > Subject: Re: Can Maven edit a WAR?
> >
> > On 03/08/2012 12:04 PM, Jared Hall wrote:
> > > I would like to be able to modify the contents of a WAR file.
> > >
> > > Goal: I would like to be in a directory with my WAR and a pom.xml.
> > When I type 'maven configure', I would like maven to apply a filter to
> > some of the files in the war, and then leave behind the exact same
> WAR,
> > with the filters applied. I don't need to compile any files, I just
> > need to apply some filters to some files that are already in a WAR.
> > >
> > > The motivation for this is that I compile something that is still
> un-
> > configured. I throw the war into my test environment and configure it.
> > If it passes, I graduate it to production and re-configure it.
> > >
> > > Note: I don't care whether or not I use Maven or something like a
> > scripting language to accomplish this. The end goal is what I
> described
> > above, one typed command that reconfigures the WAR. I thought Maven
> > might be able to do most of the leg-work for me.
> > >
> > > Any help is appreciated, thanks.
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
> > Maven is not a scripting tool.
> > It has very definite ideas about how software gets built and this is
> > not
> > really in line with its ideas.
> > In dealing with Maven, you have to conform to its process or you will
> > have a miserable life until you submit.
> > "Resistance is futile" is your best mantra when planning to do battle
> > with Maven.
> > Stop before you start.
> >
> > Try Ant.
> > It is the Border Collie of Java tools and wants to do whatever you
> want
> > to do.
> > It has no preconceived ideas about "Best Practices".
> >
> > Ron
> >
> > --
> > Ron Wheeler
> > President
> > Artifact Software Inc
> > email: rwhee...@artifact-software.com
> > skype: ronaldmwheeler
> > phone: 866-970-2435, ext 102
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
>
>
> ______________________________________________________________________
> This message, including any attachments, is confidential and contains
> information intended only for the person(s) named above. Any other
> distribution, copying or disclosure is strictly prohibited. If you are not
> the intended recipient or have received this message in error, please
> notify us immediately by reply email and permanently delete the original
> transmission from all of your systems and hard drives, including any
> attachments, without making a copy.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Reply via email to