castor

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. File
    castor-1810.diff
    04/Jan/07 9:53 PM
    563 kB
    Edward Kuns
  2. Java Source File
    PlantagenetDescriptor.java
    04/Jan/07 1:17 PM
    4 kB
    Carlo Romero
  3. XML File
    UnboundedElementInXSDChoice.xsd
    04/Jan/07 1:16 PM
    1 kB
    Carlo Romero

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
Edward Kuns added a comment -

Fix delivered.

Show
Edward Kuns added a comment - Fix delivered.
Hide
Permalink
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
Permalink
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
Permalink
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
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: