ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Perry Dykes" <pdy...@us.ibm.com>
Subject Lessons learned moving from ant 1.2 -> 1.3
Date Thu, 05 Apr 2001 13:08:40 GMT

Wanted to post some experiences moving from 1.2 to 1.3, and hopefully gain
some clarification. If I have missed the boat on a feature, like to know
that. Three problems I have found in moving production ant xml to 1.3: exec
changes, delete of (empty) subdirectories is broken, and most importantly
the -logfile option does not result in the logfile being flushed to disk
(notably after the problems with a).

Hopefully this will give others a heads up as well, as it was reasonably
time consuming to regress and figure out how to make changes to accomodate
ant 1.3.

a) exec change?

In 1.2, I could use the following of snippet of code and it worked for
win2k and winnt. Key attribute is the executable.

     <exec dir="${TOOLS_HOME}\prod\bin"
              executable="tools_batch.bat"
              failonerror= "false" >
          <arg value="${TOOLS_HOME}\${testcase_path}" />
          <arg value="${testcase}" />
      </exec>

Now, I have to use the following becuase on my winnt systems, it fails,
win2k is ok. Not sure why it fails yet as I just get a CreateProcess
error=2.

      <exec dir="${TOOLS_HOME}\tools\bin"
              executable="${TOOLS_HOME}\prod\bin\tools_batch.bat"
              failonerror= "false" >
          <arg value="${TOOLS_HOME}\${testcase_path}" />
          <arg value="${testcase}" />
      </exec>

After some experiementing with 1.3, if the "executable" value is in the
path, a fully qualified name is not required and a bad "exec dir" path
won't matter, even if tool not in the "exec dir" path on windows NT.  In
1.2, somehow, ANT did seem to take into account the "exec dir". I hate to
many paths to PATH env variable. In 1.2 I did simply created an "exec dir"
entry that pointed to where I sit my executables for the driver build, the
path to the bit was not in the PATH env variable. In 1.3, that does not
work for me.  The failure should be caught in a try/catch, because it maybe
causing my c) problem. But I have also noticed the c) problem happens in
other cases as well. Also, this problem applies to a program.exe as well as
a program.bat.

Like to have ant assume that it should look in the "exec dir", then goto
the PATH, then fail. Once fails, a more helpful message than java stack
dump to win32 CreateProcess error=2 would be nice as well.

b) delete broken

recursive delete of subdirectories are broken, e.g. is broke.

   <delete>
      <fileset dir="${APPSVR_HOME}\installedApps" includes="deployed_*/**"
/>
    </delete-->

    <delete includeEmptyDirs="true">
      <fileset dir="${APPSVR_HOME}\temp" >
        <include name="**/**" />
      </fileset>
    </delete>

The two examples above (and I tested many, many variants), show what I used
to do (excluding the new includeEmptyDirs attributes new to 1.3). The
directory trees below the installedApps\deployed_someear\x\y\z are all
emptied of files correctly, however the intermediate emty directories are
not deleted. This is documented already in a couple of other posts, so I'll
get directly to my plea.

Noticed on the list someone said just make a 1 line fix.  I diffed the 1.4
source with 1.3, and there are many lines of change, more than I was
comfortable with changing. I really like ant, but not having a delete that
works well and is functional is a major drawback. I now have to bundle a
unix like rm.exe command to meet my deadlines, but that is kind of hacky
and the reason I started using ant in the first place.

If someone could post the 1 line fix to really fix this and how to build
and add to Jar (try to me more of user of ant than a developer), I would
appreciate.

c) logfile not written out immediately

I create batch files that write the logs out, and do tail -f on them. In
1.3, the -logfile option when used does not result in the logfile being
flushed to the disk as 1.2 did. It does eventually when enough output is
written, but for XML typos or errors early in the execution (e.g. problem
a) above) the log does not get written out. Problem with this is, if a XML
problem, or some other error occurs in say the first 300-400 lines of
output, the logfile does not get dumped for me.

My view is that if the logfile option is used, there better be a logfile
created. Also like an option that would act like the unix tee command, e.g.

ant ... -logfile fname -sendtoscreenalso.

If I missed something, great, let me know. Hope this will save others some
time.

Perry Dykes
pdykes@us.ibm.com



Mime
View raw message