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