Hello,

Although my personal option is that you should have 1 build for all your
environments and configure all environment specific issues within that
environment (using JNDI or config.properties), there are other options.

On SpringONE'07 Joris Kuipers gave a presentation about this topic.
Some information about that is available in his blog. [1]
Read "Code samples from SpringOne 'Beyond the obvious' talk"

(Since you're in EAR/WAR-land, his posting about "Using a shared parent
application context in a multi-war Spring application" might be of
interest to.)

With kind regards,
  Marco Beelen
  Software Engineer
  IPROFS 

[1]: http://blog.springsource.com/main/author/jkuipers/




-----Original Message-----
From: EJ Ciramella [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 04, 2008 2:32 PM
To: Maven Users List
Subject: RE: Building for different environments - how do _you_ do it?

Can you expand on this or is there an example of this some where?

We ARE in ear/war land though...

-----Original Message-----
From: Dave Feltenberger [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2008 11:43 PM
To: Maven Users List
Subject: Re: Building for different environments - how do _you_ do it?

Another possibility, if you're not in a J2EE container and don't
necessarily have access to JNDI (or don't want to rely on server config
vs. a self-contained JAR/WAR) is to package all the environment
configurations together and use something like Spring and an environment
variable to filter a context or properties file.  I've found this to be
very useful, as the same artifact can be deployed in dev, prod, staging,
qa, etc. without having to re-build and risk potential differences in
the artifacts.

Dave

On Tue, Jun 3, 2008 at 2:22 PM, Paul Davis <[EMAIL PROTECTED]> wrote:

> The best thing is to NOT create a different build for different 
> environments.
>
> When environment specific stuff is needed (EARs and WARs) look up the
info
> from JNDI and put that configuration on the server.
> Then if something needs to change, you don't need to create a new
build.
>
> If you have to do it, you could probably create a profile for each 
> environment setting a variable.
> Then the files specific to that environment could be "filtered" based
on
> the
> value of that variable.
> You'd just specify the profile to use when creating the build.
>
> On Tue, Jun 3, 2008 at 11:14 AM, EJ Ciramella
<[EMAIL PROTECTED]>
> wrote:
>
> > So how are other people building for both dev and other
environments?
> >
> >
> >
> > For example, how does one support multiple environments like the
> > following:
> >
> >
> >
> > 1 - Dev integration
> >
> > 2 - QA stack 1
> >
> > 3 - QA stack 2
> >
> > 4 - QA stack 3
> >
> > 5 - Staging
> >
> > 6 - Prod
> >
> > 7 - local developer builds
> >
> >
> >
> > How do other people support variables that can be the same from
local
> > builds through production but support the option to change them at
the
> > last minute?  Are people building multiple version of say an ear 
> > deployment to support all the different environments?
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

**********************************************************************
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286 
**********************************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to