Wow, man, like I am....aroused. Mark
-----Original Message----- From: Vic Cekvenich [mailto:[EMAIL PROTECTED] Sent: Monday, March 03, 2003 6:38 PM To: [EMAIL PROTECTED] Subject: Re: deploy with ant, best practices 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 issue. hth, .V 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 [mailto:[EMAIL PROTECTED] > Sent: Friday, February 28, 2003 1:30 AM > To: [EMAIL PROTECTED] > 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 > > ${app.name}.war > ${app.name} > /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 > ${app.name}.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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
