ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Ant Principles (Taskdef storage)
Date Thu, 20 Apr 2000 11:49:09 GMT

The idea of deploying separate zip.jar and unzip.jar files seems wierd to
me, since they'll obviously be using the same helper classes. How about
this: we bundle them in one jar and put a "tasksets.xml" file in the jar
that looks like:

<taskset name="compression">
     <taskdef name="zip" classname=""/>
     <taskdef name="unzip" classname=""/>

Now if we're using jdk1.2, we can put all of these jars in the classpath
(as well as non-task jars like tools.jar) and call
ClassLoader.findResources("tasksets.xml"), which will return an enumeration
of all the tasksets.xml files in all the jars. If we're using JDK1.1, we'd
have to search the classpath by hand. In any case, when we encounter
something like this in the build file...

<load taskset="compression"/>

...we can find the "compression" in one of the tasksets.xml files, and load
all the tasks associated with it using Class.forName().

So to install a set of tasks on a system, you'd just need to add the
appropriate jar(s) to the classpath. To distribute a set of tasks, you need
to write an xml file and include it in your jar. The downside is that
you're loading all tasks from a single classloader, which might cause
conflicts if different tasksets are using different versions of the same

On the topic of managing versions, it might make sense to put version
numbers on our tasksets, to give people some clue as to why the project
they just downloaded won't build...

<taskset name="compression" version="1.2">

If we assume that increases in the major digit are not backwards
compatible, and increases to the minor digit are, then something like...

<load taskset="compression" version="1.1"/>

... would check to make sure that we have version 1.x of the taskset
installed on the system, where x >= 1. just a thought...

Matt Foemmel
ThoughtWorks, Inc.

                    Bodewig              To:              
                    <bodewig@bost        cc:                                          
                    .de>                 Subject:     Re: Ant Principles (Taskdef storage)
                    03:41 AM                                                             
                    respond to                                                           

>>>>> "KA" == Kuiper, Arnout <> writes:

 >> From: Thomas Haas []

 >> Where do classes go, which are used by several optional tasks,
 >> which are not part of the core?

 KA> 1. Scan the directories mentioned in the <taskdefs
 KA> extpath="foo:bar/ext"/> path.
 KA> 2. Scan the $user.dir/ant/taskdefs directory.
 KA> 3. Scan the $install_dir/taskdefs directory.
 KA> 4. Scan the $install_dir/taskdefs/optional directory.

 KA> Note that an optional directory for 1. and 2. are not very
 KA> useful.  Optional tasks have only meaning in the Ant distribution
 KA> itself.

Either you have misunderstood Tom's question or I don't understand
your answer.

I think Tom is talking about something like a zip and an unzip
task. Those would be in zip.jar and in unzip.jar in any one of the
first three paths. Both share - say - ZipEntry.

Where should that go? Put them into the CLASSPATH or into yet another
ext-directory for "non task JARs"? The second one sounds like your 4.
but I think it also applies to tasks not distributed with Ant.

OK, my example is very simple. I'd say create a single zip task with
an action attribute taking "store" and "extract" but I think you get
the idea.


View raw message