ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim McCune <t...@channelpoint.com>
Subject RE: Some thoughts about ant plugins
Date Tue, 12 Sep 2000 21:24:11 GMT
Since Ant is XML-based anyway, why not use a "plugin.xml" instead of a
"plugin.properties"?  In your example, you're already using dot-separated
hierarchies anyway, which just gets kludgy in properties files.

For example:
<tools>
	<tool name="mkdir">org.apache.tools.ant.taskdefs.Mkdir</tool>
	<tool name="javac">org.apache.tools.ant.taskdefs.Javac</tool>
	...etc
</tools>

Check out
http://www.merlotxml.org/docs/UserGuide/UserGuide-1.0.html#chapt-plugins and
http://www.merlotxml.org/docs/plugins/plugin-dev-guide.html to see how
Merlot does plugins, which are _very_ much along the same lines of what
you're talking about here, right down to the custom Plugin Class Loader.

Tim McCune
Software Architect, ChannelPoint
"You know I don't like toast."  "Oh, I think you'll like this toast.  It's
free."  "Free you say?"  "And, it's toast!" -- Brak

-----Original Message-----
From: Paul Philion [mailto:philion@acmerocket.com]
Sent: Tuesday, September 12, 2000 9:32 AM
To: Ant-Dev
Subject: Some thoughts about ant plugins


Greetings -

I've been kicking around some ideas about a plugin architecture for
Ant. Here's what I think, so far:

- Each plugin resides in one JAR file, called an Ant Plugin Tool file
(.apt)

- Each plugin file may contain several Tools (allowing for a
'tools.apt' for the standard tools).

- The plugin file contains a Properties files at the root level,
called "plugin.properties", containing the following line for each
tool in the plugin file:

  tool.<toolname>=<fully qualified class name>

i.e..

  tool.mkdir=org.apache.tools.ant.taskdefs.Mkdir
  tool.javac=org.apache.tools.ant.taskdefs.Javac
  tool.chmod=org.apache.tools.ant.taskdefs.Chmod
  tool.deltree=org.apache.tools.ant.taskdefs.Deltree

(Note: the "tool." prefix is used to allow new types of data for
future expansion.)

- The ant deployment will have a standard directory, "plugins", that
the *.apt files will reside in.

- When ant starts up, it will scan the plugin directory, load the
"plugin.properties" from each *.apt file and construct a top-level
"tool to JAR name/class name" mapping for all available tools.

- Optional: ant can dump this top-level map as
"tools-cache.properties" in the plugin directory. Each time each
starts, it will simply compare the modification time of the
"tools-cache.properties" file to that of all the installed plugin
files and rebuild the cache only when there are new or changed JAR
files. (For simplicity, it is assumed that "new" plugin files will
have more recent mod dates than the cache file. In situations that
this is not the case, that use can a) manually remove the cache file
or b) use a --build-cache option on ant.)

- Ant will contain a custom class loader to load the specific tools
from the correct JARs when they are requested.

- The custom class loader (or a "load tool" factory) will check the
class instance to make sure that it conforms to the Task interface.

- A DefaultTask would be added to the standard tool set to handle any
tags that did not have tools. The implementation would simply log
error messages.

- An AptTask would be added to the standard tool set to generate *.apt
files.

Some Issues:

- In this scenario, several *.apt files could contain different
implementations for the same tool. I recommend that we simply take the
first definition that we find and log any attempts to redefine that
tool. Optionally, we could add a "plugins" attribute to the <project>
tag to give preference to certain plugin files. The tools in those
plugin files would be added first, and the standard "tools.apt" would
always be loaded last.

- I would really prefer to see Tasks use the Flyweight pattern, but I
haven't done enough research to offer specific recommendations about
how to do it.

- I almost see that the tasks would be fired my some sort of "task"
event, giving them everything they need to know (reference to current
target, etc.) to perform their task, instead of the current
call-setters-to-configure-then-execute. I see almost a "task request"
object that contains the attributes and contents (from build.xml).

- Paul Philion

Mime
View raw message