ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mpfoe...@ThoughtWorks.com
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
line...

<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
"tasks.properties" file from the jar, which would map tasks names to
classnames...

Matt Foemmel
ThoughtWorks, Inc.


                                                                                         
                                                         
                    James Duncan                                                         
                                                         
                    Davidson                  To:     ant-dev@jakarta.apache.org         
                                                         
                    <james.davidson@en        cc:                                     
                                                            
                    g.sun.com>                Subject:     Re: Ant Principles         
                                                            
                                                                                         
                                                         
                    04/21/00 09:48 AM                                                    
                                                         
                    Please respond to                                                    
                                                         
                    ant-dev                                                              
                                                         
                                                                                         
                                                         
                                                                                         
                                                         





> 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