You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Berin Loritsch <bl...@apache.org> on 2003/05/20 17:18:52 UTC

Free-form ANT Task Structure

I want to write a task that allows me to embed XML configuration
information to set up some integration tests using JUnit as a
base.

I can live with a DOM or JDOM to interpret and transform into my
configuration objects.  The concept is based on some work I originally
did to extend JUnit for testing Avalon components.  The thing is
that I want to change the way the JUnit test runner works so that
I can preload my Avalon container with the proper components,
and I can iterate through all the implementations of a component
with the same test against it.

In order for this to happen properly, I need to pass configuration
information to the container.  The two options I have is to require
the configuration as a separate file, or to allow the configuration
to be embedded in the ANT task.

I would prefer to have the config embedded so that I can work on
things one step at a time.  Otherwise--I have to resort to the
file approach.

What are your thoughts?  Is it too much to ask for free-form
elements as a sub of a task, or do they HAVE to map to objects?



Re: Free-form ANT Task Structure

Posted by peter reilly <pe...@corvil.com>.
Here is a simple example task:

import java.util.*;
import org.apache.tools.ant.DynamicConfigurator;
import org.apache.tools.ant.Task;

public class Dy
    extends Task
    implements DynamicConfigurator
{
    private String subName;
    private Map attributes = new HashMap();
    private List elements   = new ArrayList();
    
    public Object createDynamicElement(String name) {
        Dy dy = new Dy();
        dy.setSubName(name);
        dy.setProject(getProject());
        elements.add(dy);
        return dy;
    }

    private void setSubName(String subName) {
        this.subName = subName;
    }

    private String getSubName() {
        return subName;
    }
    
    public void setDynamicAttribute(String name, String value) {
        attributes.put(name, value);
    }

    private void print(int level) {
        StringBuffer b = new StringBuffer();
        for (int i = 0; i < level; ++i) {
            b.append("  ");
        }
        String indent = b.toString();
        for (Iterator i = attributes.entrySet().iterator(); i.hasNext();)
        {
            Map.Entry e = (Map.Entry) i.next();
            log(indent + e.getKey() + " = " + e.getValue());
        }

        for (Iterator i = elements.iterator(); i.hasNext();) {
            Dy dy = (Dy) i.next();
            log(indent + "element " + dy.getSubName());
            dy.print(level + 1);
        }
    }
    
    public void execute() {
        log("Dy");
        print(1);
    }
}

and the build.xml:
<project name="t" default="t">
  <target name="t">
    <mkdir dir="classes"/>
    <javac srcdir="src" destdir="classes"/>
    <taskdef name="dy" classname="Dy" classpath="classes"/>
    <dy>
      <integration-test>
        <test on-components="foo,bar">
          <include name="**/XYZComp/*Test"/>
          <configuration>
            <xyz-comp id="foo"/>
            <zyx-comp id="bar">
              <arbitrary value="null"/>
            </zyx-comp>
          </configuration>
        </test>
      </integration-test>
    </dy>
  </target>
</project>

generates:
Compiling 1 source file to /home/preilly/proj/learning/dy/classes
Dy
  element integration-test
    element test
      on-components = foo,bar
      element include
        name = **/XYZComp/*Test
      element configuration
        element xyz-comp
          id = foo
        element zyx-comp
          id = bar
          element arbitrary
            value = null

Peter.

On Tuesday 20 May 2003 17:38, Berin Loritsch wrote:
> peter reilly wrote:
> > To embed the config information, the easiest
> > is to map the info to objects.
> >
> > Ant introspection is very powerfull and easy
> > to use for normal java data object.
>
> The problem is that it only works when you know in advance
> what the configuration elements are going to be.  In this
> example, that is not the case.
>
> > Alternatively one can use the DynamicConfigurator
> > interface. This provides the name of the unknown element
> > and the name/value of unknown attributes.
>
> That might be something worth pursuing.  Now, can I have
> a mixture of DyanimicConfigurator objects and mapped
> objects in the *same* task?

Yes.

>
> Or more importantly as a child of one of the mapped
> objects?

Yes - you may implement what you want.
Ant's introspection looks add the addX and setX patterns
before handing the element/attribute over to DynamicConfigurator.

>
> For example:
>
> <integration-test>
>    <test on-components="foo,bar">
>      <include name="**/XYZComp/*Test"/>
>      <configuration>
>         <xyz-comp id="foo"/>
>         <zyx-comp id="bar">
>           <arbitrary value="null"/>
>         </zyx-comp>
>      </configuration>
>    </test>
> </integration-test>
>
> The child of the <configuration/> element is completely
> free-form, although the rest of the task elements would
> map to real objects.
>
> Is there an Task already written that uses the DynamicConfigurator
> where I can see how it works with it?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org


Re: Free-form ANT Task Structure

Posted by Berin Loritsch <bl...@apache.org>.
peter reilly wrote:
> To embed the config information, the easiest
> is to map the info to objects.
> 
> Ant introspection is very powerfull and easy
> to use for normal java data object.

The problem is that it only works when you know in advance
what the configuration elements are going to be.  In this
example, that is not the case.

> 
> Alternatively one can use the DynamicConfigurator 
> interface. This provides the name of the unknown element
> and the name/value of unknown attributes.
> 

That might be something worth pursuing.  Now, can I have
a mixture of DyanimicConfigurator objects and mapped
objects in the *same* task?

Or more importantly as a child of one of the mapped
objects?

For example:

<integration-test>
   <test on-components="foo,bar">
     <include name="**/XYZComp/*Test"/>
     <configuration>
        <xyz-comp id="foo"/>
        <zyx-comp id="bar">
          <arbitrary value="null"/>
        </zyx-comp>
     </configuration>
   </test>
</integration-test>

The child of the <configuration/> element is completely
free-form, although the rest of the task elements would
map to real objects.

Is there an Task already written that uses the DynamicConfigurator
where I can see how it works with it?



Re: Free-form ANT Task Structure

Posted by peter reilly <pe...@corvil.com>.
To embed the config information, the easiest
is to map the info to objects.

Ant introspection is very powerfull and easy
to use for normal java data object.

Alternatively one can use the DynamicConfigurator 
interface. This provides the name of the unknown element
and the name/value of unknown attributes.

Peter

On Tuesday 20 May 2003 16:18, Berin Loritsch wrote:
> I want to write a task that allows me to embed XML configuration
> information to set up some integration tests using JUnit as a
> base.
>
> I can live with a DOM or JDOM to interpret and transform into my
> configuration objects.  The concept is based on some work I originally
> did to extend JUnit for testing Avalon components.  The thing is
> that I want to change the way the JUnit test runner works so that
> I can preload my Avalon container with the proper components,
> and I can iterate through all the implementations of a component
> with the same test against it.
>
> In order for this to happen properly, I need to pass configuration
> information to the container.  The two options I have is to require
> the configuration as a separate file, or to allow the configuration
> to be embedded in the ANT task.
>
> I would prefer to have the config embedded so that I can work on
> things one step at a time.  Otherwise--I have to resort to the
> file approach.
>
> What are your thoughts?  Is it too much to ask for free-form
> elements as a sub of a task, or do they HAVE to map to objects?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org