Jesse - Ok.
I (myself) would prefer a standard JAR format. But I would like a tool that scans the classes in a project and generates a manifest. I don't like to hand edit data files that can easier be generated. But then, I'm lazy. (I'm not familiar with the "Class-Path: xxx.jar" global attribute. Can you point to some docs? Thanks.) - Paul > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 12, 2000 2:26 PM > To: [EMAIL PROTECTED] > Subject: Re: Some thoughts about ant plugins > > > 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 >
