tomcat-dev mailing list archives

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

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"/>
  ...
</project>

* 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:

  "\project\classes\main;classes\util"

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:

  "\project\classes\main;\project\classes\util"

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

Index: ant/src/main/org/apache/tools/ant/taskdefs/Javac.java
===================================================================
RCS file:
/home/cvspublic/jakarta-tools/ant/src/main/org/apache/tools/ant/taskdefs/Jav
ac.java,v
retrieving revision 1.11
diff -r1.11 Javac.java
309c309,310
<           StringTokenizer tok = new StringTokenizer(compileClasspath, ":",
---
>           StringTokenizer tok = new StringTokenizer(compileClasspath,
>                                                     File.pathSeparator,

Glenn.


-----Original Message-----
From: James Duncan Davidson [mailto:james.davidson@eng.sun.com]

jon * wrote:
> 
> on 11/25/99 10:10 AM, Twiggs, Glenn <Glenn_Twiggs@bmc.com> wrote:
> 
> > The compileClasspath variable has already been "localized" before
reaching
> > this point. That is, on WIN32 systems, all the ":" are ";" and the "/"
are
> > "\".  This is why the error occurrs. The fix works if your XML is coded
as
> > 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
I
> 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.

.duncan

Mime
View raw message