struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vic Cekvenich>
Subject Re: deploy with ant, best practices
Date Mon, 03 Mar 2003 23:38:06 GMT
Since I get the joy of being on many clients sites I pick up things. 
Here is something that started being better than Ant (Ant is still great 
for builds).
So here is how I develop:

Lets call this method "developing live".
Using Resin you can make it persist a session to a file, during 
development. Since resin (and tomcat) reload classes and xml (resin only 
I think, and resin also complies for you, using Jikes.,etc).
So my dev. environment is excaly like a war, with lib under web-inf.
As soon as I change a class or xml, it is auto recompiled and session is 
saved to file.
The effect is that as I change a few lines, I can hit refresh on the 
page I am on, and have the new expects.
Without this I had to build, (maybe restart if xml changed), login, and 
navigate to the problem screen, usually 5 screens down.

With "live", I can just touch up a file and refresh. And auto ant at end 
of day.

Also on topic of development.... if you have a laptop or high end 
graphics card, you can develop with 2 screens! (A client told me 1st). 
It's so cool:
My left monitor shows a split of browser and app server console.
My right monitor shows IDE code full screen. So I change code in editor, 
and in my left monitor I click refresh browser... and I see console 
ouput log.debug. Sweet.
I use Eclipse because of plug ins and SWEET cvs. Eclipse makes CVS easy 
and reliable. Everything else I have tried over the years, made CVS an 


Jaye Bass wrote:
> My ant targets build directly into my webapp directories...the root
> location is set in an env variable. This really seems to work for us on
> a variety of systems (linux, windows, and occasionally macs) from
> development to ultimate deployment and maintenance.
> -----Original Message-----
> From: Dan Allen [] 
> Sent: Friday, February 28, 2003 1:30 AM
> To:
> Subject: deploy with ant, best practices
> I have been studying ant very thoroughly over the past two days, and
> I completely understand the file from top to bottom, including how
> to reload the application using the <reload> tag imported from
> org.apache.catalina.ant.ReloadTask.  However, I am stuck on an
> issue.
> Assuming that I follow the techniques from the book Struts Kick
> Start, I create a development tree such as
> ${app.home}
>     /build
>     /deploy
>     /object
>     /src
>     /lib
>     /web
>         /WEB-INF
>         /META-INF
> then the actual target tree (under tomcat/webapps) is the typical
> ${}.war
> ${}
>     /WEB-INF
>     /WEB-INF/lib
>     /WEB-INF/classes
>     /META-INF
> Okay, now stay with me here.  Assume that I currently have the
> application running under tomcat.  If I build the .war file from the
> build/ directory and place it into ${app.home}/deploy, then copy
> it to ${}.war under tomcat/webapps, it isn't going to
> automatically expand over the current running tree.  It just sits
> there until I kick tomcat (restart it) after deleting the running
> application directory.
> So what I did instead was I made the build/ directory the actual
> running application directory so it just copied over the "live"
> files directly as they were updated by javac.  Then a simple
> "reload" would cause the application to start using the updated
> files.
> The question on the table is as follows.  How do you get tomcat to
> expand an updated .war file over a currently running application
> before you reload it?  It seems wrong to have the "live" application
> the target of my build process.
> The goal here is to update the running application without having to
> restart tomcat and without having to use the running application as
> the target of the build process.  I want to be able to copy the
> updated .war file into the tomcat/webapps folder and have it expand
> it over the running application files.  Is this unreasonable to
> expect this?  How does everyone else do it.  Surely you are not
> restarting tomcat all day.
> Dan

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message