ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject [RFE] Richer Task Specification
Date Wed, 14 Jun 2000 09:58:24 GMT

I am not sure of the usuall process for a Request For Enhancement (RFE) but
I guess I'll just say what I want :P. I want to see the ability to specify
tasks more richly. 

Request 1:

Currently there is a whole bunch of classes that gain reusability through
inheritance. This IMHO is a bad idea. While you could factor out the
relevant code into helper classes it still doesn't seem good design. For
instance many people have been wanting various tasks to match files in
various ways etc and duplicating code or else calling out to other static

What I would like is some method of knowing how to preprocess properties so
that they are in form task wants. So instead of tasks such as javac calling
resolvepath/translatepath/whatever it would already be passed to the task
pre-processed. This would also mean it would be possible to have properties
that are not strings and in fact could effectively be any Object.

So to get this working there needs to be two problems solved, namely
conversion and processing. It may be the case that these two processes can
be combined into one step (thou I am not sure if this is the right way(tm) ).

To write a converter you simply have to implement the interface

interface Converter
  Object convert( Object object );

and then register it at some registry via

myRegistry.registerConverter( new StringToFileConverter(), 
                              File.class );

and then convert it just before passing to task via

myRegistry.getConverter( String.class, File.class ).convert( param );

So thus you could have a task with a property of type File. It would
automatically be converteed from a string to a File object. 

I did almost an identical thing recently but unfortunately I don't own the
code. I believe similar things occur in a number of projects such as BML at and jedit at The only problem I had
was that I ended up with an excessive number of Converter classes. This
could be aleviated if one converter accepted multiple input types and
registered itself as a converter for multiple types.

The processing could occur in a similar way with a registry and processors
etc. This would allow you to specify the attribute "src" as having a type
of "ant:filelist" or "ant:file" and automatically
translate/resolve/whatever to it. 

The problem is how do we know what processing any particular property
wants. We could do it by type (ie all File[] get processed vi translation
and reolving) however that is inflexible and can lead to problems when
different tasks want the property output in same manner but processed

Hence there are a number of approaches that I can see. Use JavaBeans
properties. The bean spec allows the author to add arbitary attributes to
fetures (ie properties) which could be used to specify the type. This may
be a possibility but it requires the task author also write an extra
BeanInfo class to specify extra attribute for property if they want any
sort of special processing. It also ties the project to java which others
may not want (python-ant anyone ? :P).

Alternatively a parser with schema support could be used and a
schema-fragment for each task be created. The schema fragment is then
merged with other fragments to form a fully happening schema. Tasks that
dont have any pre-processing requirements don't define a schema-fragment
and have theirs automatically generated from task class. So for task you would look for resource /com/biz/myTask.schema and if it
not existing then  automatical generate it. 

Problems with the schema approach are the task developer has to be
partially aware of what a schema is and it also makes it impossible to
dynaically add taskdefs (which is something I ask for below :P). 

To decrease task developers cognitive load we could even auto-generate the
BeanInfo/schema based on javadocs comments. ie if we see a @task-type then
we know what comes next is the typename. This requires two passes (ie one
to write code and one specialised javadoc pass) but this could be hidden
from developer if we wanted.

I could go on and on about hows/whys to implement but I guess you get
picture here :P so I will stop.

Request 2:

Would it be possible to have a bunch of standard ant properties in Tasks
that effect project in other manners.

For instance it would be nice to have 

<javac ant:classpath="blah.jar" .... />

This would mean that this task is automatically loaded by a new classloader
that included "blah.jar" and whatever else was specified. There are other
things that I would like to have thou are not sure of their merits. Some of
the things that people have mentioned recently include assynchronicity and
working directory thou there could be other factors that i haven't thought
of yet ...

Request 3:

Could taskdefs be specified immediately. ie. move the main chunk of it from
init to execute. This would allow a single build file to compile the
taskdefs it needs and then use those in turn to do further processing. I
have to run build twice to get this solved and it bugs the hell out of me :P.

Request 4:

A standardised set of taskdefs for invoking standard C/C++ tools (ie tasks
like make, cpp, cc, link etc). I keep writing hacky ones for whatever
particular compiler I am using at the time that are basically execs. Most
of my compilations have relatively standard parameters so maybe it would be
an idea to amalgamate them all into one task that then delegates to
appropriate lower-level driver ????


I got a whole bunch of other requests but gotta eat now and besides they
are even more ludicrous than the ones I said above. So thoughts on it ?
Good/bad idea ? Improvements ? volunteers ? If people think it is a good
idea and no one volunteers I can can do it but it wont be a while
unfortunately :<



| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."          |
|       -Abraham Lincoln                               |

View raw message