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:[EMAIL PROTECTED]> NetBeans, Open APIs <http://www.netbeans.org/> tel (+4202) 3300-9161 Sun Micro x49161 Praha CR
