Simplify binding file synatx by collapsing the various *Binding structures into one, i.e. componentBinding

First, I'll add a new <componentBinding> element (global and local to <binding>) to binding.xsd.

Alright, new <componentBinding> added to binding.xsd, classes re-generated and copied to the correct place. As a result of this, descriptors have been moved to 'descriptors' packages wherever applicable.

Having said that, I am very much in favor of actually removing those generated classes from the repository altogether. Given how easy it has been to copy the newly generated classes over, build test and run CTF without any problems, I think at least this part is ready for removal.

There's a few things to define:

a) in what directory the classes from binding.xsd should be generated. My preference would be build/generated-sources/castor

as this would be 100% in sync with Maven. maven allows configuration here, though.

b) Addition of a new target to codegen/build.xml so that the classes will be generated and compiled right after the core classes of codegen have been compiled.

c) Removal of codegen/src/main/resources/org/exolab/castor/builder/binding/binding.xml, as clearly we cannot use a binding when generating the classes for the binding XML schema.

d) Addition of code to the Ant build file so the generated classes are included in the JAR(s) being produced.

I am still not sure whether this is actually achievable, though.

Hmm ... just tried to remove the generated binding classes from codegen/src/main/java, and it doe not work as assumed. Basically, the remaining classes in codegen/src/main/java/org/exolab/castor/builder/binding don't compile anymore, and without a fully compilable code generator, of course, code generation will not work anymore .. .

What's interesting, with the Castor Maven plugin (for code generation, that is), one could create a dependency to the latest plugin available, and instruct Maven to generate the sources before compilation of the files in codegen/src/main/java. Does anybody have an idea how to go about this using Ant (without having to manually provide a fully working JAR file as part of the SVn repo ?

Have a look at the following plugin configuration added to codegen/pom.xml:

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>castor-maven-plugin</artifactId>
<version>1.0</version>
<configuration>
<schema>src/main/resources/org/exolab/castor/builder/binding/binding.xsd</schema>
<packaging>org.exolab.castor.builder.binding</packaging>
<properties>src/main/resources/org/exolab/castor/builder/binding.generation.properties</properties>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.castor</groupId>
<artifactId>castor</artifactId>
<version>1.1-M3-SNAPSHOT</version>
</dependency>
</dependencies>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
</plugin>

Nice, isn't it ? Taken binding.xsd, generates classes from it and puts them to target/generated-sources/castor. And no dependency on sources (and thus compilation of those), as the plugin relies on a binary JAr available at the Maven repos.

I wouldn't want to make a Castor build dependent on having a JAR file of a previous build around. We definitely have a chicken-egg problem here in that we need the source generate (including binding) to be built to run the source generator to create the binding XML classes ... but we need the binding XML classes to build the source generator.

As far as building from Maven ... maybe we want to do this:

1) Build the binding classes using a previous JAR, then
2) Build codegen, then
3) Build the binding classes using the new classes, then
4) Build codegen one more time and make the JAR

Since the binding classes are not used to generate code, the above is inconvenient but necessary and suffiicent, IMHO.

Ideally, we could find a way to build codegen WITHOUT binding and make sure that our binding XML never uses a binding file. Then we could do this in a straightforward way. But it we want codegen to be "current" we currently would need to generate the binding code twice.

As far as I know, we only have this problem with codegen. With the CTF and other components, we will just need to build codgen first, then generate any needed code, then build the rest.

No objection to your moving the code to a new package.