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
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: Possible TaskDef donation
Dominique Devienne wrote: This is indeed interesting. I do something quite similar for another purpose (scans a JAR for all classes having a give static method signature, executes all these methods, gathering the meta-info required, generate a XML file then stuck into the JAR's META-INF directory). Something I do is to restrict scanning classes to only those that match a given patternset to speed things up (you often know which part of your package tree to look things, or could use a naming convention to find things faster). This makes the scanning quite a bit faster (we have big JARs). All this to say that you specific use case if very useful, but the more generic action all scanning the classes of a JAR and doing something that ultimately updated the JAR somehow would be even more useful. Allowing to plug over 'actions' rather than the default 'looking for services' would be very very useful IMHO. Easy change to make--I can make it a protected action (the actual check). What are your dependencies? BCEL? Do you load the actual classes (so need dependent classes on the classpath)? Standard JVM. I use JarFile to read the JAR contents, and JarOutputStream to write the new JAR. I construct a new URLClassLoader that uses the current classloader as the parent, and loads the input JAR in as well. I then scan the contents of the JAR only looking at the .class entries. I load the class, and perform my checks on the class itself. Thanks for sharing this with us. --DD PS: BTW, I don't think you can edit the JAR in place... Would be nice though. I guess we could make it something where you can use a directory instead of the JAR. It would alter the scanning code though. Do you want me to post what I have?
