Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (herse.apache.org: domain of jwcarman@gmail.com designates
 64.233.182.186 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=BNseRE0VKkA08yXO6TVkFOJiwATbAqaRlRO9/FbyEhSVvy5Uh2Tk4JDfiubJxoNqAUIogN/RLFgXFSooS+foFW2BxiOAwF0KbaYJjudkczvBCoqKPBM/4Xy1uRLOWHlj4WfDwuTzKJKCz9Unh7bcCy5EoNM49vXRd9/KKqNilak=
Message-ID: <eb4296c40701230414g395bc37ct7ddf3c7428677e4e@mail.gmail.com>
Date: Tue, 23 Jan 2007 07:14:46 -0500
From: "James Carman" <james@carmanconsulting.com>
Sender: jwcarman@gmail.com
To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Subject: Re: [configure] - context.xml vs Tomcat Admin
In-Reply-To: <f8b39ace0701221005g2750912ep9b87e66901798063@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <45B4A4FE.7000705@gdcjk.com>
	 <eb4296c40701220653j7d5fdb32oee06243ee043cf9@mail.gmail.com>
	 <45B4DB0F.5070409@gdcjk.com>
	 <f8b39ace0701220949t1bb5a4f6i13fade75595463e8@mail.gmail.com>
	 <eb4296c40701221000l240e3d9eofbd960fc770c22e2@mail.gmail.com>
	 <f8b39ace0701221005g2750912ep9b87e66901798063@mail.gmail.com>

The paranoid point of view can be a good thing.  So far, though, it
has worked for us.  We just have different "flavors" of our
build.properties file for each of our environments.

On 1/22/07, Craig McClanahan <craigmcc@apache.org> wrote:
> On 1/22/07, James Carman <james@carmanconsulting.com> wrote:
> >
> > "Using the server admin lets you take the same web application
> > and deploy it *unmodified* in different environments where you really
> > want to connect to different services (such as a testing server, a
> > staging server, and a production server)."
> >
> > If you make your build system smart enough, you can have it generate
> > your context.xml file with the correct settings (Velocity comes in
> > handy here) depending upon your targeted environment (test vs. prod).
> > I usually do this using a build.properties file in Ant.  In order to
> > change your targeted environment, all you have to do is change the
> > build.properties file and that's it.
>
>
> Sure, you can do a lot more work in your build script if you want to :-).
>
> But, I have also seen lots of big shops that are totally allergic to testing
> one version of an app but then needing to build it again before deployment.
> They want to be sure the bits they test are *exactly* the bits that are
> actually deployed.  For this scenario, having an ability to configure
> resources externally is extremely valuable.
>
> Come to think of it, this is very similar to the attitude we have in Apache
> projects, where a proposed release needs to have the actual bits we are
> voting on (versus a promise to build from a particular SVN tag or revision
> number later on).
>
> Craig
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org