ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Duncan Davidson <james.david...@eng.sun.com>
Subject Re: Ant Principles
Date Fri, 21 Apr 2000 14:48:39 GMT

> 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 following...
> 
> <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 with
> 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
> "tasks.properties" file, which maps task names to class names (same format
> as the current defaults.properties file). We could then create a
> modules.properties 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
there. 

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

.duncan



Mime
View raw message