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]
