ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brill Pappin" <>
Subject RE: Platform independent classpath in build.xml?
Date Wed, 31 May 2000 17:29:22 GMT

- Brill Pappin

> -----Original Message-----
> From: Conor MacNeill []
> Sent: May 31, 2000 10:59 AM
> To:
> 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

> > 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
( 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);
	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...

View raw message