>>>>> "PP" == Paul Philion <[EMAIL PROTECTED]> writes:
As Jesse has pointed out, there has already been a discussion along the lines of your post some time ago - hmm, <URL:mailto:[EMAIL PROTECTED]> 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 well. 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. Stefan
