You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Conor MacNeill <co...@m64.com> on 2000/07/01 17:01:00 UTC
RE: unless and nested includes/excludes undocumented?!
> -----Original Message-----
> From: Vassilis Rizopoulos [mailto:Vassilis.Rizopoulos@Rubus.com]
> Sent: Thursday, 29 June 2000 20:35
> To: 'ant-dev@jakarta.apache.org'
> 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
RE: unless and nested includes/excludes undocumented?!
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
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
conor@cortexebusiness.com.au
Cortex eBusiness
http://www.cortexebusiness.com.au
> -----Original Message-----
> From: Tom Cook [mailto:tcook@ardec.com.au]
> Sent: Monday, 3 July 2000 10:23
> To: ant-dev@jakarta.apache.org
> 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:Vassilis.Rizopoulos@Rubus.com]
> > > Sent: Thursday, 29 June 2000 20:35
> > > To: 'ant-dev@jakarta.apache.org'
> > > 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
> >
>
RE: unless and nested includes/excludes undocumented?!
Posted by Tom Cook <tc...@ardec.com.au>.
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:Vassilis.Rizopoulos@Rubus.com]
> > Sent: Thursday, 29 June 2000 20:35
> > To: 'ant-dev@jakarta.apache.org'
> > 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
>