Proposal: Object offeriong CLASSPATH abstraction

[Thomas Haas <th...@softwired-inc.com>]

Hi all

To provide nested elements in the JUnit task I needed something to build
nested classpath definitions. Browsing through the code (javac, javadoc,
java) I come along the idea of creating a general class representing
classpath alike structures.

The basic object is called "Path" which describes a list of PathElement
and other (recursiv) Path objects. A PathElement itself describes a
single location being either a (jar)file or a directory (containing
classes).
A task like "java" would have one Path object representing the classpath
to be used. A task like "javac" may have different Path object
representing different classpathes like classpath, extdirs,
bootclasspath, ...

A task like JUnit, javac, javadoc can use this implementation to define
nested classpath definitions:

<sometask>
    <somepath path="optional:path;definition" >
        <element location="/path/to/some.jar" />
        <element location="/path/to/some/classes" />
        <path path="optional:path;definition">
            <element location="/path/to/some/other.jar" />
            <element location="/path/to/some/other/classes" />
        </path>
    </somepath>
    ...
    <someotherpath>
        <element location="/yet/another/path/to/some.jar" />
        <element location="/yet/another/path/to/some/directory" />
    </someotherpath>
</sometask>

The object implementing "sometask" must provide the methods
"createSomepath" and "createSomeotherpath" which return the Path
objects. The nesting of path definitions is handled by the Path object.

Some rational:


   * The javac task does some proccessing of the variant path
     definitions. I beleive proccessing structured path definitions is
     easier than always manipulate strings.
   * 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.
   * The class is named path as it may represent variant classpath like
     pathes and could even be used to represent the path environment
     variable as used on unix and windows systems.
   * A single element of a path is called PathElement as lack of
     phantasie for a better name.

I am using it reight now in the current JUnit task implementation and it
made nested classpath definitions very easy.
If the proposed classes get accepted I would like to propose to use them
to implement nested classpath definitions in javac, havadoc, java and
all other tasks dealing with classpath alike structures (I wanted to
provide a patch to javac, but did not understand the whole thing right
away). Maybe even project could store the classpath env. variable as
Path object.

Both classes are currently placed in org.apache.tools.ant, but it may
fit anywhere else as well.
I am still unsure about the naming of the classes, methods and
properties any improvemnts on this are especially welcomed.

I hope you like the stuff and awaiting you opinions.

- tom (even an hour erlier than usually ;-)


--
* Thomas Haas                    <ma...@softwired-inc.com>
* SoftWired AG                   <http://www.softwired-inc.com/>
* Technoparkstr. 1  ***  CH-8005 Zurich  ***  +41-1-4452370