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
>
