ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Ant Principles
Date Fri, 21 Apr 2000 19:20:27 GMT

cool. I think I was more concerned with being able to distribute groups of
tasks, as opposed to to loading groups of tasks. ie I didn't want to have
to the zip task and the unzip task in separate jars. I also liked the idea
of using different classloaders per module, to avoid conflicts between
different versions of the same class.

We can remove a layer of abstraction, however, if we say that the module
name is the same as the jar name, and that any other jars that it depends
on (tools.jar or junit.jar, say) belong in the classpath. So the following

<load module="cvs"/>

...would cause ant to look for a cvs.jar file (or cvs.tsk file), which
would get loaded in its own classloader. Ant would then read the
"" file from the jar, which would map tasks names to

Matt Foemmel
ThoughtWorks, Inc.

                    James Duncan                                                         
                    Davidson                  To:         
                    <james.davidson@en        cc:                                     
          >                Subject:     Re: Ant Principles         
                    04/21/00 09:48 AM                                                    
                    Please respond to                                                    

> Has any thought been given to bundling tasks together so that they can be
> loaded as a group? For example, if a build file contained the
> <project name="foo">
>     <load module="jdk" />
>     <load module="cvs" />
>     ...
> </project>

Hadn't thought of that... Though this would require a different approach
than the tiered approach that we've been talking about and would require
some sort of named registry to associate the string "jdk" with a set of
tasks. I would like to stay away from such a registry if possible.

> So if we want to go this route, the next question is how to bundle the
> taskdefs into modules. A lot of the proposals I've seen haven't dealt
> the fact that a taskdef may depend on multiple other jars to get its job
> done (javac needs the tools.jar, for example).

Jar manifest entries take care of this. One of the assumptions that we
make, at least that's stated, is that the JDK is installed. In the
special case of tools.jar, we need to make sure that the compiler is on
the classpath when ant starts.

> So let's assume that a
> module is actually a collection of jars, one of which contains a
> "" file, which maps task names to class names (same
> as the current file). We could then create a
> file in the ANT_HOME directory (or where ever) that
> looked like:
> jdk=/jdk1.2.2/lib/tools.jar:lib/ant-jdk.jar
> cvs=lib/ant-cvs.jar
>  ...

Ok, so this avoids the central registry, but creates a different layer
of abstraction... Also, you've got a problem with that absolute path in

But at core, it's another layer of abstract that I'm not sure we really


View raw message