ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Glick <Jesse.Gl...@netbeans.com>
Subject Re: Some thoughts about ant plugins
Date Tue, 12 Sep 2000 18:26:15 GMT
Paul Philion wrote:
> I've been kicking around some ideas about a plugin architecture for
> Ant. Here's what I think, so far:

Someone else had a similar proposal, did anything come of it...?

> - 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.mkdir=org.apache.tools.ant.taskdefs.Mkdir
>   tool.javac=org.apache.tools.ant.taskdefs.Javac

Or a little more conventionally, the JAR manifest could work like
JavaBeans and other specs:

--------%<--------
Manifest-Version: 1.0

Name: org/apache/tools/ant/taskdefs/Mkdir.class
Ant-Task: mkdir

Name: org/apache/tools/ant/taskdefs/Javac.class
Ant-Task: javac
--------%<--------

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

Which is already needed, for referrable types (FileSet, Path, ...) which
are now extensible. Suggest "Ant-Type: FileSet" etc.

> - 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.)

Why is this useful? Getting the manifests and parsing them should not
require a noticeable amount of time.

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

...and this class loader should extend URLClassLoader so that you can
use the standard "Class-Path: xxx.jar" global attribute to request
separate extension libraries where appropriate. The initialization of
this classloader could also search for the JDK tools.jar so that we
would be spared a mess in the startup script. (Ideally java -jar
.../ant.jar -Dant.home=... <args> would be possible on 1.2.)

> - 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.

ProjectHelper should already do exactly this: fail and tell you why.

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

Using the manifest syntax above, you could just as easily write the
manifest yourself and use the <jar> task.

> - 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.

Or just treat any duplicates as an error and leave it at that. Might
however be useful for <project> to be able to specify additional plugin
JARs not included in the standard location, assuming the path to them is
predictable: for example, in a single directory, bootstrap.xml creates a
custom.apt JAR (how about simply *.jar instead?), and the build.xml has
a <project extensions="custom.apt"> to use it.

-Jesse

-- 
Jesse Glick   <mailto:Jesse.Glick@netbeans.com>
NetBeans, Open APIs  <http://www.netbeans.org/>
tel (+4202) 3300-9161 Sun Micro x49161 Praha CR

Mime
View raw message