I have a separate "deploy" target using the "<unwar>" task to unroll
the WAR file myself. Build your WAR normally and then unroll it for
Tomcat. You could easily then use the "<reload>" task as desired.

I'd also like to take a moment to express my (mild) distaste at
forcing your build tree to look like your WAR file structurally.
The "<war>" task will let you specify the bits and pieces
by destination, so you can put your sources where they make sense
to you (the human) instead of where their eventual output forms
will make sense to the appserver. For example, I keep all my
configuration files and resource properties files in an "etc"
directory and tell "<war>" to go fetch them from there:
    <target name="war" depends="compile,generate">
      <war destfile="dist/${app.name}.war" webxml="etc/web.xml">
        <fileset dir="web"/>
        <lib dir="lib">
          <include name="*.jar"/>
        </lib>
        <classes dir="target/classes"/>
        <classes dir="etc">
          <include name="*.properties"/>
          <include name="hibernate.cfg.xml"/>
          <include name="cache.ccf"/>
        </classes>
        <webinf file="etc/struts-config.xml"/>
        <webinf dir="lib">
          <exclude name="*.jar"/>
        </webinf>
      </war>
    </target>


> -----Original Message-----
> From: Dan Allen [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 28, 2003 2: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
> 
> -- 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
> Daniel Allen, <[EMAIL PROTECTED]>
> http://www.mojavelinux.com/
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
> "I am the GOD.....the GOD...of house!" 
>  -- Leeloo
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
> 
> ---------------------------------------------------------------------
> 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]

Reply via email to