castor
  1. castor
  2. CASTOR-1840 Stream-line support for XPATH expressions in binding file
  3. CASTOR-1843

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

    Details

    • Type: Sub-task Sub-task
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.1 M2
    • Fix Version/s: 1.4
    • Component/s: XML code generator
    • Labels:
      None
    • Number of attachments :
      0

      Description

      As all the various XBindings point to the same type (ComponentBindingType), there's no added value in keeping those. I thus propose to remove all of them, and to create one (unique) <componentBinding>.

        Activity

        Hide
        Werner Guttmann added a comment -

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

        Show
        Werner Guttmann added a comment - First, I'll add a new <componentBinding> element (global and local to <binding>) to binding.xsd.
        Hide
        Werner Guttmann added a comment -

        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.

        Show
        Werner Guttmann added a comment - 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.
        Hide
        Werner Guttmann added a comment -

        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.

        Show
        Werner Guttmann added a comment - 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.
        Hide
        Werner Guttmann added a comment -

        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 .. .

        Show
        Werner Guttmann added a comment - 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 .. .
        Hide
        Werner Guttmann added a comment -

        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 ?

        Show
        Werner Guttmann added a comment - 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 ?
        Hide
        Werner Guttmann added a comment -

        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.

        Show
        Werner Guttmann added a comment - 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.
        Hide
        Werner Guttmann added a comment -

        Just committed that change to codegen/pom.xml (adding comments about life-cycle integration). As such, I should be able to exclude the checked-in code from compilation with Maven. Life would be easier, though, if we moved the three classes mentioned above to a new package

        org.exolab.castor.builder.binding.utils

        Any objections ?

        Show
        Werner Guttmann added a comment - Just committed that change to codegen/pom.xml (adding comments about life-cycle integration). As such, I should be able to exclude the checked-in code from compilation with Maven. Life would be easier, though, if we moved the three classes mentioned above to a new package org.exolab.castor.builder.binding.utils Any objections ?
        Hide
        Edward Kuns added a comment -

        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.

        Show
        Edward Kuns added a comment - 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.
        Hide
        Edward Kuns added a comment -

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

        Show
        Edward Kuns added a comment - No objection to your moving the code to a new package.

          People

          • Assignee:
            Werner Guttmann
            Reporter:
            Werner Guttmann
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Time Tracking

              Estimated:
              Original Estimate - 1 hour
              1h
              Remaining:
              Remaining Estimate - 1 hour
              1h
              Logged:
              Time Spent - Not Specified
              Not Specified