Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
From: "Brill Pappin" <john.pappin@jmonkey.com>
To: <ant-dev@jakarta.apache.org>
Subject: RE: Platform independent classpath in build.xml?
Date: Wed, 31 May 2000 13:29:22 -0400
Message-ID: <BEEPKHMEGMGIEMBFMOINAEIDCEAA.john.pappin@jmonkey.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <001201bfcb10$c22da5f0$80dc1fcb@cognet.com.au>
Importance: Normal


- Brill Pappin

> -----Original Message-----
> From: Conor MacNeill [mailto:conor@m64.com]
> Sent: May 31, 2000 10:59 AM
> To: ant-dev@jakarta.apache.org
> Subject: RE: Platform independent classpath in build.xml?
>
>
> >
> > It would be very easy to just use the standard Ant separator for entries
> > (namely a ",") and have ant parse it into the OS dependant
> separator when
> > required... not problem, instant solution.
> >
>
> I don't think "," is the standard ant separator. Where does it say this?

It doesn't say it anywhere, but its all over Ant... call it the "unwritten
rule"...

> > In fact, when I first tried to use it, that's exactly what I
> assumed would
> > happen... needless to say I was disappointed to find that I had to use a
> > native separator :(
>
> Its actually better than you realise. As it stands ant will accept a path
> specification with either Windows or Unix standard path separators and
> translate to the native platform's representation. This makes ant very
> accepting. In general I try to stick to the Unix style separators in my
> build files even though I work mostly on NT.

The trouble with it is that we assume that we're going to get a unix or a
windows path separator... what happenes on another OS, such as JOS
(www.jos.org)... does anyone know what will happen on an Amega? (not that
amega is likely to ever implement a recent JDK, but the concept is sound).
My point is, that a particular token separator is used everywhere in ant,
except in a classpath...

There is also no reason that the system classpath can't work in conjunction
with an "ant classpath"... once the ant classpath is converted to a native
path at runtime, the system classpath could be appended if desired.

> BTW, I wrote a class to tokenize paths into path components and I then
> rewrote Project.translatePath to use it. This actually addresses a problem
> raised by Phil Hanna to support absolute paths of the form
> C:/blah. It does
> this without affecting the ability for single letter Unix paths to be
> supported. The tokenizer is reusable in other places in the ant code where
> you need to iterate over the components of a path.
>
> I have attached it for comment.

Looks like it would work, but you have hard coded the path separator chars
in some places... I think you can do the same thing without doing that... in
fact I have done that very thing... here is a rough method that will be
something like what I did, although in a slightly different context...
I don't think it will compile without a little work (I didn't try it anyway)
but you can see what I'm talking about.

public static final File[] tokenizePaths(String working) {
	ArrayList filelist = new ArrayList();
	if (working != null) {
		if (working.indexOf(File.pathSeparator) > -1) {
			// this is a series of paths.
			// we need to tokenize the string.
			if (!working.endsWith(File.pathSeparator)) {
				// append a token, for the tokenizer.
				working = working + File.pathSeparator;
			}
			StringTokenizer tok = new StringTokenizer(working, File.pathSeparator);
			while (tok.hasMoreTokens()) {
				filelist.add(new File((String) tok.nextToken()));
			}
		} else {
			// this is a single path.
			File file = new File(working);
			filelist.add(file);
		}
	}
	return (File[]) filelist.toArray();
}

As you can see, at no point do I use a hard-coded path separator... and
because of that, this method should work on *any* java compliant OS,
regardless of what unique path separators it uses...