Re: Free-form ANT Task Structure
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Free-form ANT Task Structure
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?