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]
