ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <>
Subject Re: Ant Principles (Taskdef storage)
Date Sun, 30 Apr 2000 00:12:31 GMT
I really like tasksets. Those that like one taks per jar can do that
and those that want to have multiple taks per jar can do the same thing.

In particular all the basic core tasks will be in one jar and described
using XML the same way all other tasks are. No specials except
for the fact that the system preloads them.

And once tasks are described using XML, we could start using validating
parsers by describibg in the taskset the syntax for the tasks. Then one
could say:

<load taskset="compression" lib="z"/>
<z:zip ... >

and actually use namespaces for the different tasks. We could
always have parser validation as an option for ANT. wrote:
> 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=""/>
>      ...
> </taskset>
> 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
> class...
> 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">
>      ...
> </taskset>
> 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.
>                     Stefan
>                     Bodewig              To:
>                     <bodewig@bost        cc:
>                     .de>                 Subject:     Re: Ant Principles (Taskdef
>                     04/20/2000
>                     03:41 AM
>                     Please
>                     respond to
>                     ant-dev
> >>>>> "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.
> Stefan
View raw message