You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Laurent PETIT <lp...@sqli.com> on 2004/06/10 02:50:14 UTC
Deploy a webap to multiple environments (test, pre-prod, prod)
Hello,
I recently read a thread about this subject, but was not entirely convinced
by the answer.
I think this is a very common problem : you develop a webapp, and you have
to deploy it on multiple configurations : generally one for each
test-process environment : internal ( integration server ), in
pre-production on the client network, and eventually in production on the
client network.
It is common that you then have to setup different levels for logs,
different database schema names, different pathnames, ... generally in some
well identified properties files.
I saw an answer to this problem, which was to setup multiple anemic maven
projects which will hold the properties differences.
I'm not sure this is a "recommended best practice" for the problem ?
What do you folks think about it ?
What do you do in your own projects ? (even if it is not as "a beautiful
solution" as it should be, what does *work* for you ?)
Thanks in advance,
--
Laurent PETIT
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Deploy a webap to multiple environments (test, pre-prod, prod)
Posted by Laurent PETIT <lp...@sqli.com>.
Very good pointers, thanks a lot !
----- Original Message -----
From: "Tim Shadel" <ti...@pobox.com>
To: "Maven Users List" <us...@maven.apache.org>
Sent: Thursday, June 10, 2004 8:21 PM
Subject: Re: Deploy a webap to multiple environments (test, pre-prod, prod)
> Have you looked through Vincent Massol's slides here?
>
> http://www.pivolis.com/pdf/Enterprise_Builds_V1.0.pdf
>
> http://www.pivolis.com/pdf/J2EE_projects_Maven_V1.1.pdf
>
> http://www.pivolis.com/pdf/Distributed_Agile_V1.0.pdf
>
> --Tim
>
> Laurent PETIT wrote:
>
> >Hello,
> >
> >I recently read a thread about this subject, but was not entirely
convinced
> >by the answer.
> >
> >I think this is a very common problem : you develop a webapp, and you
have
> >to deploy it on multiple configurations : generally one for each
> >test-process environment : internal ( integration server ), in
> >pre-production on the client network, and eventually in production on the
> >client network.
> >
> >It is common that you then have to setup different levels for logs,
> >different database schema names, different pathnames, ... generally in
some
> >well identified properties files.
> >
> >I saw an answer to this problem, which was to setup multiple anemic maven
> >projects which will hold the properties differences.
> >
> >
> >I'm not sure this is a "recommended best practice" for the problem ?
> >
> >What do you folks think about it ?
> >
> >What do you do in your own projects ? (even if it is not as "a beautiful
> >solution" as it should be, what does *work* for you ?)
> >
> >Thanks in advance,
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Deploy a webap to multiple environments (test, pre-prod, prod)
Posted by Tim Shadel <ti...@pobox.com>.
Have you looked through Vincent Massol's slides here?
http://www.pivolis.com/pdf/Enterprise_Builds_V1.0.pdf
http://www.pivolis.com/pdf/J2EE_projects_Maven_V1.1.pdf
http://www.pivolis.com/pdf/Distributed_Agile_V1.0.pdf
--Tim
Laurent PETIT wrote:
>Hello,
>
>I recently read a thread about this subject, but was not entirely convinced
>by the answer.
>
>I think this is a very common problem : you develop a webapp, and you have
>to deploy it on multiple configurations : generally one for each
>test-process environment : internal ( integration server ), in
>pre-production on the client network, and eventually in production on the
>client network.
>
>It is common that you then have to setup different levels for logs,
>different database schema names, different pathnames, ... generally in some
>well identified properties files.
>
>I saw an answer to this problem, which was to setup multiple anemic maven
>projects which will hold the properties differences.
>
>
>I'm not sure this is a "recommended best practice" for the problem ?
>
>What do you folks think about it ?
>
>What do you do in your own projects ? (even if it is not as "a beautiful
>solution" as it should be, what does *work* for you ?)
>
>Thanks in advance,
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Deploy a webap to multiple environments (test, pre-prod, prod)
Posted by "Charles N. Harvey III" <ch...@alloy.com>.
A lot of people have these issues, so don't feel strange.
I see two ways to do this and I think Chuck Daniels covered more in his
latest
post.
1) Just like you can with Ant, create parametrized variables in
different config
files. Then work with your maven.xml to ensure that you build different
versions of the war file. So, "maven war:dev", "maven war:staging" and
"maven war:production" are all goals in your maven.xml file. With
each one
you point to a different properties file that stores the different values
that get put into the parameters that were previously setup.
2) What I personally do is to have multiple config files, like Brett
said. I
have a log4j-development.properties, log4j-staging.properties.....
You get the idea. In my tomcat's server.xml I have a context param setup
as "lifecycle". Each webapp usually needs a servlet that runs first
to do some
initialization of variables, like configure log4j. In this servlet
you can
read the value from the server.xml and configure log4j appropriately.
What I also do is set a System.property( "lifecycle", tomcatLifecycle
) that
can then be read by any class in my webapp.
I don't use Hibernate but I use OJB. I have 40 classes configured
but there
is the main repository.xml file which sets up which database I am
going to
talk to. I usually have 3 databases setup, one for each level (dev,
stag, prod).
I setup 3 connection instances in this file. Each connection uses
the same
set of files that describes the Class-to-Table relationships. Then,
when my
webapp goes looking for a connection, I make sure it gets the
connection by name.
Or, when you first initialize the application, make sure you set the
correct
connection as the default.
So, it can be done. Brett has the right idea, all of this configuration
info should
be in some kind of JNDI lookup, then it would be more secure and
centralized. But
that takes effort and planning, and most of us never get around to any
of that stuff. :)
Charlie
Laurent PETIT said the following on 6/10/2004 2:20 AM:
>Brett, thanks for the answer.
>Tough, I think I should expain myself better ... see below
>
>----- Original Message -----
>From: "Brett Porter" <br...@apache.org>
>
>
>>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.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Deploy a webap to multiple environments (test, pre-prod, prod)
Posted by Chuck Daniels <cj...@yahoo.com>.
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:apache@carlos.cousas.net]
> 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:cjd4@yahoo.com]
> > 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:lpetit@sqli.com]
> > > 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" <br...@apache.org>
> > > > 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: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Deploy a webap to multiple environments (test, pre-prod, prod)
Posted by Carlos Sanchez <ap...@carlos.cousas.net>.
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:cjd4@yahoo.com]
> 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:lpetit@sqli.com]
> > 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" <br...@apache.org>
> > > 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: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Deploy a webap to multiple environments (test, pre-prod, prod)
Posted by Chuck Daniels <cj...@yahoo.com>.
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:lpetit@sqli.com]
> 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" <br...@apache.org>
> > 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Deploy a webap to multiple environments (test, pre-prod, prod)
Posted by Laurent PETIT <lp...@sqli.com>.
Brett, thanks for the answer.
Tough, I think I should expain myself better ... see below
----- Original Message -----
From: "Brett Porter" <br...@apache.org>
> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Deploy a webap to multiple environments (test, pre-prod, prod)
Posted by Brett Porter <br...@apache.org>.
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.
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.
(If you are actually using log4j, I recommend the log4j sandbox stuff for web
applications).
HTH,
Brett
Quoting Laurent PETIT <lp...@sqli.com>:
> Hello,
>
> I recently read a thread about this subject, but was not entirely convinced
> by the answer.
>
> I think this is a very common problem : you develop a webapp, and you have
> to deploy it on multiple configurations : generally one for each
> test-process environment : internal ( integration server ), in
> pre-production on the client network, and eventually in production on the
> client network.
>
> It is common that you then have to setup different levels for logs,
> different database schema names, different pathnames, ... generally in some
> well identified properties files.
>
> I saw an answer to this problem, which was to setup multiple anemic maven
> projects which will hold the properties differences.
>
>
> I'm not sure this is a "recommended best practice" for the problem ?
>
> What do you folks think about it ?
>
> What do you do in your own projects ? (even if it is not as "a beautiful
> solution" as it should be, what does *work* for you ?)
>
> Thanks in advance,
>
> --
> Laurent PETIT
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org