ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: [Antidote] ToDo
Date Tue, 03 Dec 2002 18:17:54 GMT
Craig Campbell wrote:
 > Christoph and all interested,
 > If you don't mind I would like to tackle the custom editors.  I
 > believe I have a solution that will create customized editors for
 > each task found on the classpath instead of just tables with the
 > key/value look.  An example would be to examine all classes that
 > inherit from Task or DataType, then, through introspection, map each
 > setXXX method to a property (which would give us getXXX, setXXX,
 > functionality without causing major work to be done on each
 > task/type).

Woah now!  :)

Keep in mind that tasks don't necessarily extend from Task.  Have a look 
at the proposal/xdocs stuff (something I'm nearing to getting back into, 
I promise!).  It builds metadata files for each task using the real Ant 
rules for what makes a task a "task", as well as using the real 
IntrospectionHelper for determining what attributes and sub-elements 
each task/datatype supports.

The idea is that the proposal/xdocs stuff will generate all the metadata 
needed by Antidote, IDE's, and other tools that want to integrate with 
Ant.  Let's leverage that, unless there is a compelling reason not to.

 > Examination could be: - load from ant.jar to get
 > all the tasks we currently know about. - then start a thread to
 > examine the classpath for any new tasks that may have been added. -
 > if found update a master task list.  (The only problem is that I am
 > assuming the name of the Task would be the name of the tag element).

The task name information is available in the proposal/xdocs generated 
data.  Its either the lowercased version of the classname (minus the 
"Task" suffix if its there) or based on an @tag that is present at the 
class Javadoc level.  Have a look at the source code to Ant's tasks and 
you'll see this kind of thing there.

 > - This would allow Tasks that don't have an associated getXXX for
 > each setXXX to be able to read the current value (to do this any
 > other way we would need to revamp each Task with a getXXX method for
 > every setXXX, or at least those methods that we want to read from).

This keeps coming up.  Perhaps tasks should have getters for all their 
internal state... but then what about subelement information?  getters 
for all the adders/creators as well?


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message