ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <co...@cortexebusiness.com.au>
Subject RE: unless and nested includes/excludes undocumented?!
Date Mon, 03 Jul 2000 01:22:36 GMT
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
>  >
>


Mime
View raw message