ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Haas <>
Subject Re: Proposal: Object offeriong CLASSPATH abstraction
Date Mon, 27 Mar 2000 17:46:16 GMT
Hi Sam

Thanks for your feedback. wrote:

>   <somepath path="optional:path;definition" >
> What do you mean by optional:path;definition.  I can imagine a few
> different ways in which this can be interpreted, but instead of guessing, I
> would like to know what you are thinking.

This is equivalent to project.translatePath in the sense that it parses an
existing path definition (like the CLASSPATH env. variable). But instead of
returning a String, PathElements are added to the Path object.


  1. An easy way to add CLASSPATH as defined by the environment.
  2. The number of elements of the path definition may not be known in
     advanced, therefor it would not be possible to define the path using
     elements only.

> >       <element location="/path/to/some.jar" />
> >       <path path="optional:path;definition">
> If there were a slash added before the closing angle bracket, what would be
> the difference between these two statements?

Very good question. The generated path String will be the same. The two
following PathElement objects will be hold by the top Path object, instead of
Path object created by the statement above.

This may seems odd, read below for an explanation.

> >  * Nesting many path definitions may not always make sense. It is done
> >    this way to easily mix single element definitions a predefined path
> >    strings in any order. I think that structures like the deeply
> >    nested somepath will probably only be used the append a predefined
> >    path instead of prepending it.
> I don't understand what purpose nested path definitions would server.  Can

> you give an example where it does make sense?

The short answer:
To allow predefined pathes not only to be prepended (as by <somepath
path="..:...:...:..">) but also to put them in the middle or at the end of the
path definition. The nesting of more PathElement is only a side effect, but not
a design goal.


   * Predefined pathes may explode into many primitivs or elements.
   * Using the path attribute of the path entry, predefined pathes can only be
     prepended, but not put at the end or in the middle of a path.
   * To allow the above I first wnated to replace the path property by
     prependpath and appendpath. But then I thought this is a) somehow ugly and
     b) does not allow to put anything inbetween.
   * Adding the functionality of translating a predefined path into many
     elements to the PathElement object did not fit, because then an object
     intended to hold a single entity explodes into many, which caused
     structural problems of the hole thing.

Therefor I allowed nesting of path definitions.
I have to say, that I started using only one object representing the hole path
definition and the single entry, but this did not please me.
I also tried to directly create the path (using a shared StringBuffer) whenever
an path element occured, but than I realised, that the javac task does some
processing of the classpath, which meant reparsing the String just build from
(mostly) single elements. So I decided to build a list of some primitivs.

Maybe Path.createPath could return itself (this) instead of a new Path object,
which will lead in a single list of elements instead of a list of elements and
nested pathes.


Thinking of it, it would probably be possible to use only one object Path, with
createElement and createPath methods always returning itself (this). The
setPath and setLocation method adding String (or File) objects to a list.
Nested pathe definitions would still be possible and desired, but will always
result in a single list of things (Strings or Files).

I hope things a re clearer now, if not, let me know.

- tom

* Thomas Haas                    <>
* SoftWired AG                   <>
* Technoparkstr. 1  ***  CH-8005 Zurich  ***  +41-1-4452370

View raw message