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? > > > > >
