ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <>
Subject RE: Some thoughts about ant plugins
Date Thu, 14 Sep 2000 01:28:13 GMT
I would like to add some additional comments:

> From: Stefan Bodewig []
> >>>>> "PP" == Paul Philion <> writes:
>  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.

One of the advantages of using <taskdef>s is that it would allow for a much
rich syntax as we evolve. For example, a task may provide different
implementations based on JDK version or other parameters, the <taskdef> may
indicate which class to use on each case:

 <taskdef name="javac" >
  <classname name="${build.compiler.class}" if="build.compiler.class" />
  <classname name="org.apache.ant.taskdef.Javac.Jikes"
             if="compiler.usejikes" />
  <classname name="org.apache.ant.taskdef.Javac.Clasic" if="jdk11" />
  <classname name="org.apache.ant.taskdef.Javac.Modern" if="jdk12+" />

Here in a future wishfull thinking of <taskdef> we solve the problem of
multiple variants of a task based on parameters controlled by the user
properties. This could be very handy. And it is just preprogrammed on the
extension, itself.

>  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.

I think requiring to declare what extensions will be used, is a much better
approach. In particular it allows for ANT to recognize what is missing and
being able to say that such and such extension is missing as oppose to just
say that it cannot find this task and that one and the other one. I would
like to have something like:

 <tasklib name="weblogic_ejb" />

which declares the need for the weblogic_ejb apt extension. We could have
additional attributes to indicate where to load the extension from, if not
in the default extensions (like for tasks specialized for a particular

It would also allow for a future addition of namespaces, which could solve
issues of having tasks which happen to have the same name (e.g., <ejbc> for
weblogic ejbs and for oracle ejbs) used in a project that needs to be able
to generate for multiple environments. So one would be able to do things

	<tasklib name="weblogic_ejb" ns="web" />
      <tasklib name="Oracle_ejb" ns="ora" />

	   <ora:ejbc .... />
	   <web:ejbc .... />

Or something like that.

> Stefan

View raw message