ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: cvs commit: jakarta-ant-myrmidon/api project.xml
Date Sun, 14 Apr 2002 13:21:49 GMT
On Sun, 14 Apr 2002 22:24, Adam Murdoch wrote:
> I was thinking along (kinda) similar lines, where we start dealing with
> dependencies at a more abstract level than plain files names.  I was
> planning on adding a bunch of types and/or tasks which would allow
> classpaths and such to be specified in terms of optional packages.  There
> were 2 things in particular:

Heres a description of how the myrmidon antlib used to work. basically once I 
iron out the bugs I will backport it to ant1 (probably around the 21st).

You could declare an extension as a DataType like.

<extension id="my-extension"
            specification-vendor="Peter Donald"/>

And this allows all 6 extension attributes (ie name, spec version, specVendor, 
impl version, impl Vendor, implVendorID). Only the name attribute is 

You can also defined a set of extensions (like a fileset but containing 
extensions only) via something like the following. Note that this will read 
all the extension info from files included in the libfileset. An example

        <extension-set id="my-dependencies">
            <libfileset dir="../../">
                <include name="src/ant1compat/jar/*.jar"/>
                specification-vendor="Peter Donald"/>

You can use the above mentioned datatypes to generate correctly formatted 
manifests via something like

<jarlib-manifest destfile="../../generated-manifest.txt">
  <attribute name="Main-class" value="org.realityforg.dve.WorldGen"/>
  <extension-ref id="my-extension"/>
  <depends-ref id="my-dependencies"/>
  <options-ref id="my-options"/>

* extension refers to extension that you are exporting from library
* depends refers to an extensionSet that contains all extensions required by 
* options refers to an extensionSet that contains all extensions that will be 
used by library (if present) but will be ignored if not present. Note that 
this is NOT part of the standard ... yet ... it is just for information 

> * A FileList (i.e. <path>) implementation which evaluates to the jar for an
> optional package.  This would be useable anywhere a regular <path> could be
> (including other paths):
> <javac>
>     <classpath>
>         <library-path name="some.extension" version="1.0"/>
>     </classpath>
> </javac>

I was talking with someone else and they recomended something like 

<jarlib-resolver id="project.class.path">
  <extensionset refid="project.dependencies"/>

  <!-- first try maven to get it, then forrest, then gump or whatever 
       mapping system. -->
  <retriever class="org.apache.maven.MavenRetriever"/>
  <retriever class="org.apache.forrest.ForrestRetriever"/>
  <retriever class="org.apache.gump.GumpRetriever"/>
  <retriever class="org.apache.ant.AntRetriever"/>
  <retriever class="org.apache.jjar.JjarRetriever"/>
  <retriever class="org.apache.cjan.CjanRetriever"/>

This would generate a classpath from the specified extensionSet (or throw an 
exception if it cant match all extensions). It would check each retriever in 
order to see if it knows how to get the file for each extension. The above 
kinda assumes that each retriever has a separate map file for the libraries 
it knows about. However we could possibly encode this information in the 
build file via something like

<jarlib-resolver id="project.class.path">
  <extensionset refid="project.dependencies"/>

  <!-- try to load it from shared lib dir first -->
  <lib-repo dir="/opt/myJars"/>

  <!-- then see if maven descriptor can locate it -->
  <maven project="project.xml"/>

  <!-- then see if downloadable via url -->
     <extension name="X" url="http://..."/>
     <extension name="Y" url="http://..."/>
     <extension name="Z" url="http://..."/>

Alternatively we could use the rules on a per jar basis, something like

<jarlib-resolver property="location.prop">
  <extension ..../>

  <lib-repo path="/opt/jars:${user.home}/jars"/>
  <ant buildfile="../cli/build.xml"
  <url location="http://..."/>

which would search for jar in a library path first, then try and build it 
using ant task and finally try to download it from web if all else fails. It 
fails to find extension it would throw an exception. Once an extension is 
found the specified property is set to the location of jar.

The other idea I was thinking about is having a map file on the filesystem 
that describes the mapping between extension and physical files and how to 
get them.


Peter Donald

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message