ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig Campbell" <>
Subject [Antidote] ToDo
Date Tue, 03 Dec 2002 17:24:50 GMT
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).
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).
Mapping could be done as follows:
- In a new customizer (DOMAttributesCustomizer) the setObject() method would look like this:
     * Set the object to be edited.
     * @param value The object to be edited.
    public void setObject(Object value) {
        if(!(value instanceof DOMAttributes)) {
            throw new IllegalArgumentException(
                value.getClass() + " is not of type " + DOMAttributes.class);
        _attributes = (DOMAttributes)value;
        // Disable event generation.
        _squelchChangeEvents = true;
        // Iterate over each property, doing a lookup on the associated editor
        // and setting the editor's value to the value of the property.
        Iterator it = _prop2Editor.keySet().iterator();
        while(it.hasNext()) {
            PropertyDescriptor desc = (PropertyDescriptor);
            PropertyEditor editor = (PropertyEditor) _prop2Editor.get(desc);
            String key = desc.getName();
            String attributeValue = _attributes.getProperty(key);
            if(attributeValue == null)  {
                    _attributes.put(key, "");
        // Enable event generation.
        _squelchChangeEvents = false;
- Out of context this may need some explaining (if not please feel free to skip past this
section).  The DOMAttributes extends the Properties class, but is the class that DtdAttributePropertyEditor
requires for a value in its setValue(Object value).  If the task has an associated class that
it can inspect we create the customized editor, otherwise we fall back on the familiar table
- 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).
My final suggestion:
Create a dtd for every task that could be stored in their own jar files.  i.e. for ant.jar
the dtd would only specify those tasks that reside in the ant.jar archive, the same with the
optional.jar.  Then when a custom task on the user's side is implemented they make their own
dtd for their task(s) and put it in the META-INF directory to be picked up by our editor.
 I have already modified the AntStructure to be able to separate the Core tasks in one dtd,
and the Optional tasks in another dtd so we have that piece done already (I would just have
to submit it for inclusion in the main Ant project).  We could modify it to create a dtd based
upon classes found in a specific jar file rather than all classes found on the classpath to
accomodate the end user's creation of their own dtds.
If this sounds like something you would agree with please let me know and I will get started.
 If not let's discuss what would be better.

>>> 12/3/2002 3:07:45 AM >>>

Hi Craig (and all people interested and still lurking: Nick, Sim???)!

> I noticed that you committed something for Antidote.  I was 
> wondering if you could take a look at Bug 14138 
> ( 
> where I have requested a few enhancements to Antidote, but 
> haven't heard anything from anybody on where this is headed, 
> or what more I need to do to get this committed.

I took a look into it closely and recognized, that it is the same
implementation you showed me some time ago. We agreed way back when that the
implementation is nice but pretty slow, so that we'll start enhancing
Antidote in small steps based upon the current CVS tree!

Anyways: If you still want to contribute, there are quite some things to do!

1. Find a concept for ACSDtdElement(s) to be rendered with different icons
in the tree, based upon the current implementation.

2. Build a DTD generator for ant.jar and optional.jar and/or an
introspection addition to support custom tasks without loosing the
performance of the current DTD-based implementation.

3. Wizard to create initial projects with default tempolates.

4. Custom editors

5. nicer looks. :)

6. JavaHelp (As you proposed)

7. the other things you proposed like persistable user settings etc.

> Thanks for looking into this for me,
> Craig

Wou are welcome :)


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message