It must possible then to bundle a default context.xml file and use that one - loaded as resource through the classloader of the cli.

You missed the "TransformerTask extends org.apache.tools.ant.Task" requirement... Also include an antlib.xml file in the .jar which identifies the available tasks. Same thing for Maven: org.apache.maven.plugin.AbstractMojo + plugin.xml

Yes, I will enhance the ant task. Cool, I am learning these ant + maven tasks

I am not sure about the context file. It looks strange to me that part of the configurations are passed via command line args but the context file not. The context file is part of the user configuration and defines in your case the ironjacamar xsd files. Even the name of the file is not static.

The first xslt transformation requires exactly such a xml file. Even we could pass everything over command line, these arguments have to be written to an xml file.

The number of arguments. I think even for the IronJacamar descriptors are about 10-15 arguments required. That is compared to other descriptors not so much. If you see the schemaJava6.xml file with all the descriptors belonging together, you will end up by passing up 100 command line arguments.

I will work over the weekend for resolving the things you have mentioned.

The first xslt transformation requires exactly such a xml file. Even we could pass everything over command line, these arguments have to be written to an xml file.

Well, hacks like taking the parameters passed and writing out an XML file based on those, and then pass that could work. Maybe system properties could be used for substitution...

The number of arguments. I think even for the IronJacamar descriptors are about 10-15 arguments required. That is compared to other descriptors not so much. If you see the schemaJava6.xml file with all the descriptors belonging together, you will end up by passing up 100 command line arguments.

Yeah, it is basically two different "schools" - I find it is easier for people to understand if everything is exposed directly in the build environment files (build.xml / pom.xml) versus "hidden" in a configuration file.

However, we should also look at it from a time PoV - using a configuration file and exposing the path to that in the build environment takes the least amount of time. Improvements can always be made down the road.

Did you had a chance to look at the latest push? The current version should support almost everything you need. I couldn't test the ant task but the maven plugin task is integrated and is part of the build, e.g. it produces the ironjacamer descriptors which is then tested by the following cli-test module.