ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Burton" <>
Subject Re: Refactor of PathTokenizer - am I missing something?
Date Thu, 03 Jan 2002 21:11:57 GMT
Hello Jeff,

Given the current assumptions PathTokenizer makes for supporting colons
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 support)
colons as path delimiters for NetWare.

The following change to the PathTokenizer constructor ensures that when
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 are
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 -D
on the command line.  It doesn't matter if the existing path definition
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 build.xml
where a path was specified as a property using ":" or ";" delimiters
except for the purpose of referencing a Java property (java.class.path) or
environment variable that already used the correct path delimiters for the
underlying OS.  If you have found build.xml's where this is an issue, it
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 within
<path> or <classpath>, etc.  Then you don't run into these problems with
delimiters and don't have long, hard to read paths in your build file.  

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

Hope this helps,

Jeff Tulley wrote:
> Ok, here is where my novice-ness as to ant shows.  :)
> So, I still need to come up with a way to fix this, given the
> possibility of a path like the following:
> sys:\temp\dir1;sys:\temp\dir1
> "sys:" is the volume name, and the whole token should really be
> "sys:\temp\dir1", not "sys".  The assumption that a drive name that
> needs to be dealt with separately will only consist of one character
> breaks down on NetWare.
> If the build file is system independent, how would "/usr/bin/somedir"
> get translated on Windows?  I can see that relative paths should get
> resolved correctly, but absolute paths will always be, by definition, OS
> dependent.
> As far as "\" and "/" are concerned, NetWare can handle both.
> I guess (thinking out loud here), we could use the other form of
> StringTokenizer with returnTokens=true, and then do two lookaheads - if
> we are on a "dos based" file system, and the first lookahead is a ":",
> then do one more look-ahead like your current code.  If it is the same
> as the File.pathSeparatorChar, then ignore it.
> This could get pretty complicated.  I'll keep stewing over a more
> elegant way to solve it.
> Also, I wonder why the did not uncover this problem.  It
> seems like it should.  I'm still not sure of exactly what part of my
> build script it is that is causing the problem to occur, I just found
> the assumption and realized it was the root cause.  If I can isolate the
> cause of the problem, I'll put code in PathTest to cause the problem.
> Jeff Tulley  (
> (801)861-5322
> Novell, Inc., the leading provider of Net services software.
> >>> 1/2/02 3:34:50 PM >>>
> Jeff,
> > Yes, that is the whole class.  So, I'm thinking - it is so simple
> that
> > I must be missing something.
> What you are missing is the fact that build files are platform
> independent.
> If I take a build file with a unix-style colon separated path, it
> should
> continue to work on a Window's system. The converse is also true. Your
> change would completely break that if I understand it correctly. In
> other
> words, not only is the code platform independent but so is the
> treatment of
> the data.
> Conor

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

View raw message