ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Philion" <>
Subject Ant-Extensions, step 0 [was: Ant-Extension-Mechanism - Step 1]
Date Wed, 20 Sep 2000 13:30:30 GMT
Greetings -

I've recently (early this morning) completed the first attempt at the
"TaskLoader". It will provides the following capabilities:

- load JARs from a "plugin" directory
- grab a "meta-inf/plugin.xml" file from each JAR
- parse the XML into tasks descriptions
- act as a class loader for tasks (from it's specific JAR)

It is not perfect yet (there are some minor changes I want to make,
and currently it only supports 1.2 class loading), but I think I can
have it in good shape in short order.

The "plugin" directory and XML file name are all very flexible, so
those can be named what ever people want. The impact to existing code
is small: One new class (TaskLoader) and a few minor changes to
Project, including rewriting createTask to use TaskLoader.

The bigger changes are to the build process itself. I would like to
separate all the standard tasks into a "tasks.jar" plugin, separate
from the "ant.jar" (which should contain only the core ant classes and
minimal [or no!] tasks). The dist target will also be impacted, as
I'll need to get the plugin dir created and the plugin JARs copied
into it.

Comments? Should I send out the code for people to try themselves?
Should this go into a short-term branch just to test it?

- Paul

> -----Original Message-----
> From: Nico Seessle []
> Sent: Wednesday, September 20, 2000 5:35 AM
> To:
> Subject: Ant-Extension-Mechanism - Step 1
> Before I go further I wanted to know if the following format for
> Ant-Extension files (generated with the TaskLib-Task) is
> acceptable for you
> all?
> It currently will only support dynamic loading of task, no
> checking for
> other required libs and so on.
> As others suggested the usage of special ClassLoaders
> introduced in JDK 1.2+
> and/or the usage of MANIFEST.MF, I just dropped these
> ideas, because (1) we
> need to implement different behaviour depending of the JVM
> used (if we do it
> our own we can always do the same) and (2) I don't think
> you can easyly (and
> in a readable way) use MANIFEST.MF to do other things in
> the furure (check
> for required libs and so on) - this must be why there is a
> WEB.XML instead
> just using MANIFEST.MF :-)
> Nico

View raw message