ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: Some thoughts about ant plugins
Date Wed, 13 Sep 2000 07:01:42 GMT
>>>>> "PP" == Paul Philion <> writes:

As Jesse has pointed out, there has already been a discussion along
the lines of your post some time ago - hmm,
<> looks about
right. Part of it can be found as a very early idea in spec/core.html.

Your thoughts and the ideas of the past thread differ in some details
but agree in the big picture. 

This is what Conor referred to as "extension" mechanism when talking
about things to do before/shortly after the next release of Ant -
personally I'd prefer to see it in place before a release.

Some comments.

 PP> - Each plugin resides in one JAR file, called an Ant Plugin Tool
 PP> file (.apt)

has been "extension tasks" and .tsk but I don't stick to names.

 PP> - Each plugin file may contain several Tools (allowing for a
 PP> 'tools.apt' for the standard tools).

IIRC the discussion ended with most commiters preferring a one task per
archive approach - with the archive having the name of the task so you
could identify them easily.

Right now - where we have a lot more of optional tasks than we had back
then - I think we should allow for more than one task per
archive. Putting <wlrun> and <wlstop> into different archives looks
silly to me for example.

 PP> - The plugin file contains a Properties files at the root level,

META-INF/MANIFEST.MF seems to be the more natural choice - although a
XML file with <taskdef>s inside META-INF sounds very reasonable as

 PP> - The ant deployment will have a standard directory, "plugins",

has been $ANT_HOME/ext - again, not sticking to names.

 PP> - A DefaultTask would be added to the standard tool set to handle
 PP> any tags that did not have tools. The implementation would simply
 PP> log error messages.

Currently Ant is going to fail if it cannot find a task - and this is
how I'd like to keep it. 

The only thing I'm going to change is that Ant will only fail if you
actually try to use the task it cannot find (and it will not require
the corresponding class to exist when Ant starts anymore).

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

Yes, a task extending <jar> to create the MANIFEST.MF or .xml file
would come in handy 8^).

 PP> - In this scenario, several *.apt files could contain different
 PP> implementations for the same tool. I recommend that we simply
 PP> take the first definition that we find and log any attempts to
 PP> redefine that tool.

The user wouldn't have too much influence on the order Ant finds the
implementations - I'd say letting Ant fail would be better.


View raw message