ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Philion" <phil...@acmerocket.com>
Subject RE: Some thoughts about ant plugins
Date Tue, 12 Sep 2000 21:10:24 GMT
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: Jesse.Glick@netbeans.com [mailto:Jesse.Glick@netbeans.com]
> Sent: Tuesday, September 12, 2000 2:26 PM
> To: ant-dev@jakarta.apache.org
> 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:Jesse.Glick@netbeans.com>
> NetBeans, Open APIs  <http://www.netbeans.org/>
> tel (+4202) 3300-9161 Sun Micro x49161 Praha CR
>


Mime
View raw message