ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Christmann" <p...@priorartisans.com>
Subject antcall vs. dependency, <get> task (long)
Date Thu, 12 Sep 2002 20:05:57 GMT
I'm using the <get> task to invoke the Tomcat manager application for
"list", "stop", "start" and "install".  Rather than writing essentially
the same <get> invocation 4 times, I had put it into a single target
(the main reason I do this is because in addition to the <get>
invocation I have a bunch of debugging/file cleanup stuff that goes
along with it that I didn't want to repeat):

  <target name="manager-get" if="manager.app">
    <get
src="${webapps.url}/manager/${manager.app}?path=/${project.name}${manage
r.args}"
        dest="${manager.app}.log"
        username="${manager.user}"
        password="${manager.pwd}"/>

    <!-- Load the results of the get as properties -->
    <property file="${manager.app}.log"/>

    <!-- Load the results of the get as a string and print it -->
    <loadfile property="log.file.contents"
srcFile="${manager.app}.log"/>
    <echo message="${log.file.contents}"/>

    <delete file="${manager.app}.log"/>

  </target>

The first usage of this target is to get a list of installed Tomcat
services:

  <!-- Provide default values for the manager-get target to invoke list
-->
  <property name="manager.app" value="list"/>
  <property name="manager.args" value=""/>

  <target name="get-services" depends="manager-get"/>

After this, I can check whether the expected service for my project is
installed.  Why?  By loading the results of the <get> as a property
file, I get a series of properties of the form "/service".  So, I can
determine whether my service is installed via the property
"/${project.name}".

So now I can do things like start the service only if it exists, passing
in different property values:

  <target name="start-service" depends="get-services"
if="/${project.name}">
    <antcall target="manager-get">
      <param name="manager.app" value="start"/>
      <param name="manager.args" value=""/>
    </antcall>
  </target>

In this case, I'm using "manager-get" like a subroutine and passing the
required parameters in. 

So now I've used "manager-get" twice: once as a "depends" and once as an
"antcall".  In this case (as an "antcall"), I don't see the results of
the <get> as properties (via the <loadfile> task), since the properties
loaded inside an "antcall" are not available to the caller.  That's fine
-- I don't need them.

BUT, here's the rub: The first time I invoked "manager-get" via a
depends from "get-services", the property "log.file.contents" was set
with the results of the <get> and then printed.  Now, though, when I
invoke "manager-get" via "antcall" from "start-service", that property
is already set so the <echo> target prints the result of the "list"
call, not the "start" call -- the property is immutable so its value
isn't changed the second time.  (I could use "inheritAll=false", but
then I have to redefine all of the parameters for "manager-get", which
include standard parameters within the project (such as
"${webapps.url}", etc...).

** Specific questions **

1.  Is there a way to set a "scope" of a property, so its only available
in its target? (I think the answer is no)

2.  Is there a way to print the contents of a file without loading it
into a property? (I think the answer is no)

3.  Is this a misuse of antcall in the first place?  I'm only using it
to consolidate my repeated and identical <get> calls.

(Many thanks to Erik and Steve, as I'm picking through Chapter 7 to add
bits to my deployment.  In particular, this problem arose when I added
the debugging output to my existing targets.  I guess my main question
can be summed up as follows: In listing 7.4, the targets
"remove-remote-app" and "deploy-remote-server" are much the same.  In
particular, the <get>, <loadfile> and <echo>.  The corresponding targets
in my build had that functionality consolidated in a target invoked once
via dependency and other times via "antcall".  The problem came from the
<loadfile> property.)

PC
 
Paul Christmann
Prior Artisans
504-587-9072



--
To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>


Mime
View raw message