Because paths sometimes come from the environmet external to ant. Have a look at Thomas's path object. It combines both approaches.
Conor -- Conor MacNeill [EMAIL PROTECTED] Cortex eBusiness http://www.cortexebusiness.com.au > -----Original Message----- > From: Tom Cook [mailto:[EMAIL PROTECTED] > Sent: Monday, 3 July 2000 10:23 > To: [EMAIL PROTECTED] > Subject: RE: unless and nested includes/excludes undocumented?! > > > On an almost completely different tack with the path thingy, why not > eliminate string paths altogether and go with the syntax Tom Dimock > outlined in his message this morning. Instead of saying, > > --- > <javac src="..." destdir="..." > classpath="/patha/pathb:/pathc/pathd:./pathe"/> > --- > > say > > --- > <pathset id="compile_classpath"> > <path>/patha/pathb</path> > <path>/pathc/pathd</path> > <path>./pathe</path> > </pathset> > > <javac src="..." destdir="..." classpath.pathset="compile_classpath"/> > --- > > Gets rid of the ambiguous path separators... > > Tom > > Conor MacNeill writes: > > > -----Original Message----- > > > From: Vassilis Rizopoulos [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, 29 June 2000 20:35 > > > To: '[EMAIL PROTECTED]' > > > Subject: RE: unless and nested includes/excludes undocumented?! > > > > > > > > > > We cannot remove the ambiguity in c:/jdk1.1 but a lot of > other things > > > > are already handled - a : will always be treated as a path > separator > > > > unless there is exactly one letter in front of it for example. > > > > > > > I might be dragging this too far, but if you check for > things like 'one > > > letter infront' > > > why not check for 'one letter infront and (slash or backslash) > > > after' which > > > handles the ambiguity (I'm probablybeing awfully naive here). > > > > > > > I think it is indeed possible to parse c:/blah correctly. Originally I > > didn't think this was strictly necessary (This issue was > raised previously > > by Phil Hanna). I now think on systems with DOS style filesystems that > > c:/blah should be supported. In fact I rewrote translatePath > in terms of > > PathTokenizer to support it. > > > > The presence of Thomas' Path stuff will not eliminate the need > to parse and > > translate paths since they may be passed in from the external > environment as > > properties. Thomas has considered this. > > > > Conor > > >
