You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by alexj <al...@freesurf.ch> on 2003/03/01 00:30:02 UTC

Re: deploy with ant, best practices

I just got a copy of the Manning book Java Developpement with Ant it's a
great one.

--
Alexandre Jaquet

----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Friday, February 28, 2003 11:04 PM
Subject: RE: deploy with ant, best practices


>
>
> On Fri, 28 Feb 2003, Jaye Bass wrote:
>
> > Date: Fri, 28 Feb 2003 13:06:33 -0600
> > From: Jaye Bass <ja...@knology.net>
> > Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> > To: 'Struts Users Mailing List' <st...@jakarta.apache.org>
> > Subject: RE: deploy with ant, best practices
> >
> > 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.
> >
>
> The only aspect of this I'd be concerned about is if Tomcat happened to
> try to auto-deploy your app while it was being compiled, but is currently
> incomplete.  You might end up with some mysterious issues.
>
> Craig
>
> > -----Original Message-----
> > From: Dan Allen [mailto:dan@mojavelinux.com]
> > Sent: Friday, February 28, 2003 1:30 AM
> > To: struts-user@jakarta.apache.org
> > 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
> >
> > --
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > Daniel Allen, <da...@mojavelinux.com>
> > http://www.mojavelinux.com/
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > "I am the GOD.....the GOD...of house!"
> >  -- Leeloo
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>



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