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 Wed, 02 Jan 2002 23:43:58 GMT
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:" 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

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  (
Novell, Inc., the leading provider of Net services software.

>>> 1/2/02 3:34:50 PM >>>

> Yes, that is the whole class.  So, I'm thinking - it is so simple
> I must be missing something.

What you are missing is the fact that build files are platform
If I take a build file with a unix-style colon separated path, it
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
words, not only is the code platform independent but so is the
treatment of
the data.


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

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

View raw message