castor
  1. castor
  2. CASTOR-1810

Incorrect import lines in generated classes: dots are missing

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 1.1 M2
    • Fix Version/s: 1.1 M3
    • Component/s: None
    • Labels:
      None
    • Environment:
      Solaris
    • Number of attachments :
      3

      Description

      Import lines are not being generated properly in the descriptor classes.
      For example, the correct import line should be something like:

      import com.gs.fw.odyssey.fpml.v4_0.descriptors.PlantagenetTypeDescriptor;

      But instead it generates this:

      import com.gs.fw.odyssey.fpml.v4_0descriptorsPlantagenetTypeDescriptor;

      In addition, for the class definition it should be this:

      public class PlantagenetDescriptor extends com.gs.fw.odyssey.fpml.v4_0.descriptors.PlantagenetTypeDescriptor {}

      But instead it generates this:

      public class PlantagenetDescriptor extends com.gs.fw.odyssey.fpml.v4_0descriptorsPlantagenetTypeDescriptor {}

      I've attached the schema file I used and a sample generated class.

      1. castor-1810.diff
        563 kB
        Edward Kuns
      2. PlantagenetDescriptor.java
        4 kB
        Carlo Romero
      3. UnboundedElementInXSDChoice.xsd
        1 kB
        Carlo Romero

        Activity

        Hide
        Edward Kuns added a comment -

        Problem identified and fixed. I also updated the CTF to add the capability to generate code into a package. (Previously, the CTF only generated code into the default package.)

        After this delivery, the CTF will run using code generated from this fixed version of Castor.

        (For those reading this who are not Castor committors, we do not currently generate code for our schemas for each release, but only when the schema in question changes. This will some day change and we'll generate code for almost every schema freshly for each build.)

        Show
        Edward Kuns added a comment - Problem identified and fixed. I also updated the CTF to add the capability to generate code into a package. (Previously, the CTF only generated code into the default package.) After this delivery, the CTF will run using code generated from this fixed version of Castor. (For those reading this who are not Castor committors, we do not currently generate code for our schemas for each release, but only when the schema in question changes. This will some day change and we'll generate code for almost every schema freshly for each build.)
        Hide
        Edward Kuns added a comment -

        Fix delivered.

        Show
        Edward Kuns added a comment - Fix delivered.
        Hide
        Werner Guttmann added a comment -

        Edward, thanks for picking this up whilst I have been skiing. I noticed the same problem whilst now and then working on a separate issue, but as I didn't have any connectivity .. .

        Show
        Werner Guttmann added a comment - Edward, thanks for picking this up whilst I have been skiing. I noticed the same problem whilst now and then working on a separate issue, but as I didn't have any connectivity .. .
        Hide
        Werner Guttmann added a comment -

        > ... we do not currently generate code for our schemas for each release, but only when the schema
        > in question changes. This will some day change and we'll generate code for almost every schema
        > freshly for each build.
        Sorry, but somehow I fail to get the meaning of this statement, Eddie .. ;-(.

        Show
        Werner Guttmann added a comment - > ... we do not currently generate code for our schemas for each release, but only when the schema > in question changes. This will some day change and we'll generate code for almost every schema > freshly for each build. Sorry, but somehow I fail to get the meaning of this statement, Eddie .. ;-(.
        Hide
        Edward Kuns added a comment -

        What I meant was: For the few XML schemas within Castor where we use the source generator output as part of Castor, we currently run the source generator and check the changes into SVN – but not for every release but only when the schema in question changes.

        But some day, we won't have the generated code as part of SVN but will run the source generator on the schemas (such as the binding or mapping or CTF TestDescriptor schema) as part of the build.

        Show
        Edward Kuns added a comment - What I meant was: For the few XML schemas within Castor where we use the source generator output as part of Castor, we currently run the source generator and check the changes into SVN – but not for every release but only when the schema in question changes. But some day, we won't have the generated code as part of SVN but will run the source generator on the schemas (such as the binding or mapping or CTF TestDescriptor schema) as part of the build.

          People

          • Assignee:
            Edward Kuns
            Reporter:
            Carlo Romero
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: