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 http://www.java.sun.com/j2se/1.3/docs/guide/versioning/ .)
>
>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
>file).
>
>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
>needed.
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).
Cheers,
Pete
*-----------------------------------------------------*
| "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 |
*-----------------------------------------------------*
|