tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Twiggs, Glenn" <>
Subject RE: cvs commit: jakarta-tools/ant/src/main/org/apache/tools/ant/ taskdefs
Date Fri, 26 Nov 1999 17:24:05 GMT

I'm not sure of the best way to explain the bug I encountered, but I'll give
it a try by stepping through the methods that set the "classpath" for a
javac task. I hope this helps!

Assume the following XML is being executed under Windows NT:

<project basedir="/project">
  <javac ... classpath="classes/main:classes/util"/>

* First step: Javac.setClasspath("src/main:src/util") is called, setting
field compileClasspath to the translated value of classpath. Translation
converts ":" to File.pathSeparator and "/" to File.fileSeparator. The
resulting value of compileClasspath is:

  compileClasspath = "classes\main;classes\util"

* Second step: Javac.getCompileClasspath() is  called when the task is
executed. For each path component of compileClasspath,
Project.resolveFile(...) is called to create an absolute path. This method
splits the path on the ":" character (using StringTokenizer). The resulting
classpath is:


Which is clearly not correct. There is an "impedence mismatch" in the code.
compileClasspath is translated by setClasspath(), but getCompileClasspath()
assumes the compileClasspath is *not* translated. By splitting on the
File.pathSeparator value, the correct value will be calculated:


So, I submit the following patch to be reapplied (rolled forward? ;-):

Index: ant/src/main/org/apache/tools/ant/taskdefs/
RCS file:
retrieving revision 1.11
diff -r1.11
<           StringTokenizer tok = new StringTokenizer(compileClasspath, ":",
>           StringTokenizer tok = new StringTokenizer(compileClasspath,
>                                                     File.pathSeparator,


-----Original Message-----
From: James Duncan Davidson []

jon * wrote:
> on 11/25/99 10:10 AM, Twiggs, Glenn <> wrote:
> > The compileClasspath variable has already been "localized" before
> > this point. That is, on WIN32 systems, all the ":" are ";" and the "/"
> > "\".  This is why the error occurrs. The fix works if your XML is coded
> > classpath="dirA:dirB" and you run on WIN32 systems. See the
> > Javac.setClasspath() method for confirmation.
> >
> > Glenn.
> Ok. I'm confused. Also note that Project.translatePath() is something that
> wrote, so I'm not sure if it does the right thing as well.

So am I. Glenn, what error are you talking about? I had a small problem
with my mail (actually one of my home systems has gone totally nuts and
is sending out email dated from 1969-2099 and wrote garbage into my imap
server..) and some of it vanished from the face of the earth so I might
have missed the original problem here.

As far as I can tell from Windows and Solaris, everything is working as
expected... Now, it might be interesting to increase the parse tokens to
include ':' and ';' and '/' and '\' so that no matter how the build.xml
file was written, it'll work. But at first glance I'm opposed to that.


View raw message