ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [DISC] details of task library concept
Date Wed, 23 May 2001 15:00:37 GMT
At 10:39 AM 5/23/01 -0400, Daniel Barclay wrote:
>Peter Donald wrote:
>> Ages ago I suggested a manifest attribute
>> Ant-Class-Path: foo.jar
>> This would search all the entries in "ant.lib.path" and "ant.tsk.path" to
>> find foo.jar. This was the only mod I needed to do all complicated
>> inheritance etc. (though I had to manually throw an exception if the
>> dependency DAG had classes that depended on incompatible versions etc).
>See if the Java package versioning system can be used for that.
>(See .)
>It provides for providing an abstract name and version numbers for an
>abstract package (not a Java package name but chunk of things in a Jar 
>I thought it provided for listing depended-on packages, but maybe I'm
>confusing it with the extension loading mechanism and Jar file manifest
>Class-path: headers.
>Ant could use the regular class path (maybe with $ANT_HOME/ext/* included)
>to find Jar files, and use package versioning to identify what was found, 
>and then use dependencies (in package versioning if it does support 
>dependencies, or your proposed manifest attribute modified to use abstract 
>package names instead of concrete Jar file names) to load everything

Thats one way of doing it but it requires excessive scanning (especially if
we have small jars with few tasks in it) and is not intuitive. I suppose it
is better theoretically - it is just practically I don't think it is pretty
(especially as most people don't add versioning data into jar - which would
mean you could never depend on it).



| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |

View raw message