ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <>
Subject RE: Some thoughts about ant plugins
Date Tue, 12 Sep 2000 22:20:34 GMT
These ideas are quite in line with thoughts I have had myself.

One difference is on the usage of a properties file for the tools.
I would preffer to use XML, in particular <taskdef> elements to
define them. They will be described the same as other <taskdef> one
may define in the project itself. 

The XML may also allow to specify dependencies and conditional
availlability like it is requires for scripting and bsf.jar, etc.
Notice that we cannot assume that the APT jars are self contained.

Any thoughts?

> -----Original Message-----
> From: Paul Philion []
> Sent: Tuesday, September 12, 2000 8: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 "", containing the following line for each
> tool in the plugin file:
>   tool.<toolname>=<fully qualified class name>
> i.e..
> (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
> "" 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
> "" in the plugin directory. Each time each
> starts, it will simply compare the modification time of the
> "" 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

View raw message