-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Matt,
I disagree with many of your assertions.
Matthew Kerle wrote:
> it's doable, some of my teammates use that method, but it's a pain in
> the butt because you basically have to create 3 WARs per release (one
> for each target). considering a struts/hibernate/spring/xFire
> application is about 30mb in 3rd party jars, that's a lot of space. ok
> HD space is cheap, but it's still no excuse for poor procedure.
I'm guessing that you don't deploy all 3 WARs onto the same machine.
What's the difference between 3 different WARs and 1 WAR in 3 places?
Don't complain about disk space when the argument is 1) flawed (disk
space doesn't matter) and 2) moot (deployments to different servers).
> To do it you would basically create different build targets in your ant
> script, with each one using custom props from your build.props file, eg
> - so you would have targets dev/test/prod/all, running all would build
> wars for dev, test & prod. you use a <replace> tag to replace a
> pre-formatted pattern like ##db_user##, ##db_pwd## etc in your
> deployment descriptor with the target details. it's a crappy hack for
> bad programmers.
I completely disagree. We have complex configurations that need to
change for each environment (many properties files, etc.). Trying to
create one properties file to rule them all is impossible, and shoving
all that configuration into a (static) deployment descriptor on the
target server is kludgy and error prone, since the developers don't have
control over the server configuration.
Your choices are to have separate file sets for each environment or to
do this search-and-replace trick. I favor both, because some
configuration is best done by the programmers (properties files
including file locations, URLs, etc.) and other stuff (data source
names, passwords, etc.) are better done by server admins.
We don't deliver a WAR file to our deployment team; we give them a cvs
tag to use as the new version. It's as simple as:
$ pushd
$ cd $APP
$ ant tomcat-stop
$ ant install-clean
$ popd
$ rm -rf $APP
$ cvs checkout -r ${RELEASE_TAG} ${APP}
$ cd ${APP}
$ ant install
$ ant tomcat-start
You may find that complicated, but it's all that's required for us to
deploy our applications into ANY environment. Wanna upgrade Tomcat? No
problem:
# cd /where/you/want/tomcat/to/live
# tar xzf apache-tomcat-version.tar.gz
# (fix 'tomcat' symlink)
# (restart apps at your convenience)
No effing around with Tomcat server configuration. In fact, deploying
our production applications doesn't require root access, so out
deployment team can't really break anything.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGxIkd9CaO5/Lv0PARAilKAJ93UnlpIeG53wx0iltxo+CrDwFgTQCgg9jj
2w7a/xXTVt0zgI3hKICoL2o=
=lXKw
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
