Hi Carlos,
Here's the technique I currently use:
<goal name="load-properties">
<!-- If target is not already set, set it to 'localhost' -->
<j:set var="target" value="${target}" defaultValue="localhost"/>
<!-- Load default properties and override with target properties -->
<util:properties file="default.properties"/>
<util:properties file="${target}.properties"/>
<ant:echo>Using default overrides from ${target}.properties</ant:echo>
</goal>
<goal name="expand-properties" prereqs="load-properties">
<ant:copy
todir="..."
includeEmptyDirs="false"
overwrite="true">
<ant:fileset dir="...">
<ant:include name="..."/>
<ant:exclude name="..."/>
</ant:fileset>
<ant:filterchain>
<ant:expandproperties/>
</ant:filterchain>
</ant:copy>
</goal>
The ant:copy task illustrates how you expand all of the ${...} expressions
in the files included in the specified ant:fileset by using the
expandproperties filterchain. Simply supply appropriate values for all the
elipses (...). You can then make expand-properties a prereq for you goal
that builds your artifact.
As a bonus, if you specify a value for target and there is no
${target}.properties file (perhaps you fat-fingered the keyboard), the build
will fail and Maven reports that the file doesn't exist.
I hope that helps.
Cheers,
Chuck
> -----Original Message-----
> From: Carlos Sanchez [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 10, 2004 2:08 PM
> To: 'Maven Users List'
> Subject: RE: Deploy a webap to multiple environments (test, pre-prod,
> prod)
>
>
> Hi Chuck,
>
> I suppose you do points 3 and 4 with jelly script in maven.xml. Could you
> send an example? ;)
>
> Thanks
>
>
> Carlos Sanchez
> A Coruņa, Spain
>
> Oness Project
> http://oness.sourceforge.net
>
>
> > -----Original Message-----
> > From: Chuck Daniels [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, June 10, 2004 11:06 AM
> > To: Maven Users List
> > Subject: RE: Deploy a webap to multiple environments (test,
> > pre-prod, prod)
> >
> > This is also a question I've been meaning to ask because I
> > don't know if the technique I use is reasonable. Anyway,
> > here's what I do to create distributions for various target servers:
> >
> > 1. Parameterize the various settings in my various
> > configuration files that are target-dependent. For example,
> > let's say that my logging configuration file specifies the
> > log level for a particular component. When I build for my
> > local environment I may want this level set to DEBUG, but for
> > a production environment I may want this level set to ERROR.
> > Therefore, I might have an expression like ${log.xyz.level}
> > (where xyz is the log
> > component) in my parameterized logging configuration file template.
> >
> > 2. For each target environment, I create a distinct
> > properties file. These properties files can be named
> > logically (e.g., test.properties, production.properties,
> > etc.) or named for specific machines (e.g., abc.properties,
> > xyz.properties, etc. -- where abc and xyz are machine names),
> > whatever you prefer. I also create a localhost.properties
> > file, which contains properties values I want to use when
> > running things locally.
> > Further, I create a default.properties, which contains a
> > default value for every property I have defined for
> > substitution, so that I don't have to define every property
> > in all of the other properties files. So, continuing with
> > the example, I might have log.xyz.level=DEBUG in my
> > localhost.properties file, but log.xyz.level=ERROR in my
> > production.properties file.
> >
> > 3. In my build file, I load properties from
> > default.properties first. Then I check the value of the
> > property named 'target'. If 'target' has no value, I default
> > it to localhost. Then I load properties from
> > ${target}.properties, overriding values from
> > default.properties. To build for a target other than
> > localhost, I just specify -Dtarget=xxx on the command line
> > (e.g., -Dtarget=production), where xxx is some target server
> > (meaning I must have an xxx.properties file).
> >
> > 4. Finally, I filter copy all of my parameterized
> > configuration file templates so that my ${...} expressions
> > get substituted with the property values I have loaded
> > (default.properties and ${target}.properties). The files
> > resulting from the filter copying are what I then include in my build.
> >
> > I hope that makes sense. At present, I keep all of these
> > properties files at the root of my project (alongside
> > build.properties and project.properties), but perhaps there's
> > a better place for them. Please feel free to comment on my
> > approach, as this is something I concocted on my own. I am
> > certainly open to adjustments and alternatives.
> >
> > Cheers,
> > Chuck
> >
> > > -----Original Message-----
> > > From: Laurent PETIT [mailto:[EMAIL PROTECTED]
> > > Sent: Thursday, June 10, 2004 7:21 AM
> > > To: Maven Users List
> > > Subject: Re: Deploy a webap to multiple environments (test,
> > pre-prod,
> > > prod)
> > >
> > >
> > > Brett, thanks for the answer.
> > > Tough, I think I should expain myself better ... see below
> > >
> > > ----- Original Message -----
> > > From: "Brett Porter" <[EMAIL PROTECTED]>
> > > > I ensure all differences are externalised from the WAR
> > file. For the
> > > appservers
> > > > we use (resin, tomcat), anything in web.xml can be put outside
> > > the webapp
> > > and
> > > > added to it (<Context> definition in server.xml, <web-app in
> > > resin.conf).
> > > So
> > > > configuration goes into JNDI environment entries, context-params,
> > > resources, etc.
> > >
> > > Alas, my own personal little experience tells me that there
> > will be,
> > > at some point some practical reason (as there always seems to be in
> > > projects, since nobody's perfect, or some reason forces us
> > to do so)
> > > which forces us to have to build several different WAR
> > files for the
> > > different platforms.
> > >
> > > > For situations where you need to have whole different versions of
> > > > config
> > > files,
> > > > the webapp bundles a stage and live version (for dev we copy in
> > > > whatever
> > > suits
> > > > as part of the build - as long as the deployed version = live).
> > > An example
> > > is
> > > > log4j-quiet.xml and log4j-verbose.xml. A context-param is then
> > > set to say
> > > which
> > > > one to select.
> > >
> > > May I insist to say that I doubt (but maybe shouldn't I?) that this
> > > scenario is always possible ?
> > > For example, if you use Hibernate, you can end up having 40 mapping
> > > files, with, in each file, an attribute of the <class>
> > element set to
> > > schema="DEV_SCHEMA".
> > > ( for information, this is necessary with Hibernate since if you're
> > > using sequence based id generators, the global schema value is not
> > > inherited. I know this is a bug, but I will not stop using
> > hibernate for that reason).
> > >
> > > It seems very awkward to maintain 40 x Number of
> > configurations files,
> > > and let a context param parameterize the whole think by the
> > means of a
> > > custom hibernate mappings loadings class (and if you're using an
> > > intermediary framework to load the hibernate mappings for
> > you, it then
> > > becomes quite impossible to achieve).
> > >
> > > This is just ony one of those scenarios where I see that
> > the solution
> > > you provided above does not fill well.
> > >
> > > So, I don't think the problem can not be solved by "arrange
> > yourself
> > > not to be in such a situation", alas.
> > >
> > > So I repeat my question : if you have to build several
> > different wars
> > > for the same maven project (for some reason of another),
> > what are the
> > > techniques you use that work for you ?
> > >
> > > Or maybe I am the very only person which has ever faced
> > this situation ?
> > >
> > > > (If you are actually using log4j, I recommend the log4j sandbox
> > > stuff for
> > > web
> > > > applications).
> > >
> > > I know this is OT, but what in the log4j sandbox is so
> > great that you
> > > recommend me to use a non released of the product ?
> > >
> > > Please don't feel aggressed by my tone, if so, this is not
> > my intention.
> > > I'm just willing to clearly understand the problem.
> > >
> > > --
> > > Laurent
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > 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]
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> 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]
