ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Tulley" <>
Subject Re: Refactor of PathTokenizer - am I missing something?
Date Thu, 03 Jan 2002 23:52:51 GMT
    One thing that you are missing here is the fact that it is not a
build file directly that is triggering this problem, at least not in the
sense of the <path>, <classpath>,  and <pathelement> tags.  What is
actually giving me grief is a <javadoc> task that uses PathTokenizer. 
As far as I know, everything in the build file of mine is completely
relative.  There are no hard-coded paths at all.  This build file is
truly meant to be system-independent, and therefore it should work well.
  Simply requiring the use of other tags to overwrite the standard ones
might not solve it.  (I still need to look into it to be sure).  
    The code snippet that you provided will work as long as I do not
want to support Unix delimited paths on NetWare, since I lose that
support by parsing off of the semi-colon  only.  But, with my
alternative that I have working right now, only gets UNIX support in the
unambiguous cases, IE "/a:/b" is interpreted as two different UNIX
paths, whereas "a:/b", which could be valid in either UNIX or NetWare,
is interpreted as being a NetWare volume name of form
    It seems that I should support UNIX path names, since our OS has a
file mode that would allow you to reference our volumes in a UNIX-like
manner.  (instead of sys:/temp, it would be /sys/temp, if I am not
   I'm close to a patch, just need to test on *NIX (though my changes
to the code itself should only effect Netware, I had to change test
code, and need to make sure I did that right for UNIX)

Jeff Tulley  (
Novell, Inc., the leading provider of Net services software.

>>> 1/3/02 2:11:57 PM >>>
Hello Jeff,

Given the current assumptions PathTokenizer makes for supporting
are invalid for NetWare paths, I can't see any way in keeping with the
current implementation that would support (or would make sense to
colons as path delimiters for NetWare.

The following change to the PathTokenizer constructor ensures that
running on NetWare, only ";" will be used as a path delimiter:

    public PathTokenizer(String path) {
       String tokens = ( Os.isFamily("netware") ? ";" : ":;" );
       tokenizer = new StringTokenizer(path, tokens, false);
       dosStyleFilesystem = File.pathSeparatorChar == ';'; 

But on OS's other than NetWare, paths will be tokenized just as they
now using both ":" and ";" as path delimiters.  So now, at least when
running on NetWare, it will be possible to specify a delimited path
whereas currently it's not.

With this change, you would override any paths in a build file by
specifying the NetWare equivalent path delimited by ";"'s in a file (or equivilent) loaded by the build.xml or with
on the command line.  It doesn't matter if the existing path
uses colons since the first specified value found will be used.

I don't think this is a big issue.  I don't recall ever seeing a
where a path was specified as a property using ":" or ";" delimiters
except for the purpose of referencing a Java property (java.class.path)
environment variable that already used the correct path delimiters for
underlying OS.  If you have found build.xml's where this is an issue,
would be useful to post the relevant part.

In general, the best way to specify individial path elements is to use
multiple <pathelement location="some-jar-or-directory"/> elements
<path> or <classpath>, etc.  Then you don't run into these problems
delimiters and don't have long, hard to read paths in your build file. 

The <pathelement path="some-path" /> element probably needs to be
to support a delimiters attribute which when specified would pass the
character list into PathTokenizer.

Hope this helps,

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message