jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • Maven 2.x Castor Plugin
  • MCASTOR-37

Castor generates code which doesn't compile

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: 2.1
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None

Description

I am using the following xsd to generate java code:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://domain" xmlns:tns="http://domain" attributeFormDefault="unqualified" elementFormDefault="qualified">
...
<xs:simpleType name="BFlowType">
<xs:restriction base="xs:string">
<xs:enumeration value="component2resource"/> <!-- Component sends data -->
<xs:enumeration value="resource2component"/> <!-- Component receives data -->
<xs:enumeration value="inout"/> <!-- Component receives and sends data -->
</xs:restriction>
</xs:simpleType>
...

Using org.codehaus.mojo:castor-maven-plugin:2.0 I get compilable java code.

With org.codehaus.mojo:castor-maven-plugin:2.1 I get code that does not compile:

/*

  • This class was automatically generated with
  • <a href="http://www.castor.org">Castor 1.3.1</a>, using an XML
  • Schema.
  • $Id$
    */
    ...
    /**
  • Field enumConstants.
    */
    private static final java.util.Map<java.lang.String, BFlowType> enumConstants = new java.util.HashMap<java.lang.String, BFlowType>();

static {
for (BFlowType c: BFlowType.values()) { BFlowType.enumConstants.put(c.value, c); }

};

The final semi-colon gives the compilation error.

Perhaps the problem is already resolved in castor-codegen 1.3.2?

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Werner Guttmann added a comment - 29/Jul/11 3:02 PM

Can I please ask you to raise this as a problem over at the CASTOR project, as it seems to be a genuine problem of code generation related to one specific version of Castor ?

Show
Werner Guttmann added a comment - 29/Jul/11 3:02 PM Can I please ask you to raise this as a problem over at the CASTOR project, as it seems to be a genuine problem of code generation related to one specific version of Castor ?
Hide
Permalink
Michiel Kalkman added a comment - 02/Aug/11 8:43 AM

You can ask, but my problem is with castor-maven-plugin.

If I did what you asked, I would have to raise my issue at the CASTOR project (and then perhaps at subproject X, Y, Z, ...). Afterwards, I have to ask if this project is willing to use the most recent version of castor (although I can introduce it as a dependency to the plugin).

Is it not possible in jira to just pass my request to the castor project? I can imagine that this issue is then put ON HOLD until fixes are made in the castor project. And when that happens the status of this issue will turn into OPEN again.

I can imagine that my request at the castor project will be turned down, because I'm using version 1.3.1 of castor-codegen (through castor-maven-plugin).

BTW. castor-maven-plugin:2.1 does not use the most recent version of castor-codegen (i.e. 1.3.2). Indeed, they are incompatible as

<plugin>
...
<artifactId>castor-maven-plugin</artifactId>
<version>2.1</version>
...
<dependencies>
<dependency>
<groupId>org.codehaus.castor</groupId>
<artifactId>castor-codegen</artifactId>
<version>1.3.2</version>
</dependency>
</dependencies>
</plugin>

fails:

[ERROR] Failed to execute goal org.codehaus.mojo:castor-maven-plugin:2.1:generat
e (default) on project DocumentationSupport: Castor execution failed: org.exolab
.castor.xml.schema.Schema.getImportedSchema()Ljava/util/Collection; -> [Help 1]

Furthermore:

<plugin>
...
<artifactId>castor-maven-plugin</artifactId>
<version>2.0</version>
...
<dependencies>
<dependency>
<groupId>org.codehaus.castor</groupId>
<artifactId>castor-codegen</artifactId>
<version>1.3.2</version>
</dependency>
</dependencies>

succeeds, so there seems some regression has occurred in castor-maven-plugin:2.1.

Can we first try to solve this problem by introducing castor-codegen:1.3.2 as a dependency of castor-maven-plugin?

Show
Michiel Kalkman added a comment - 02/Aug/11 8:43 AM You can ask, but my problem is with castor-maven-plugin. If I did what you asked, I would have to raise my issue at the CASTOR project (and then perhaps at subproject X, Y, Z, ...). Afterwards, I have to ask if this project is willing to use the most recent version of castor (although I can introduce it as a dependency to the plugin). Is it not possible in jira to just pass my request to the castor project? I can imagine that this issue is then put ON HOLD until fixes are made in the castor project. And when that happens the status of this issue will turn into OPEN again. I can imagine that my request at the castor project will be turned down, because I'm using version 1.3.1 of castor-codegen (through castor-maven-plugin). BTW. castor-maven-plugin:2.1 does not use the most recent version of castor-codegen (i.e. 1.3.2). Indeed, they are incompatible as <plugin> ... <artifactId>castor-maven-plugin</artifactId> <version>2.1</version> ... <dependencies> <dependency> <groupId>org.codehaus.castor</groupId> <artifactId>castor-codegen</artifactId> <version>1.3.2</version> </dependency> </dependencies> </plugin> fails: [ERROR] Failed to execute goal org.codehaus.mojo:castor-maven-plugin:2.1:generat e (default) on project DocumentationSupport: Castor execution failed: org.exolab .castor.xml.schema.Schema.getImportedSchema()Ljava/util/Collection; -> [Help 1] Furthermore: <plugin> ... <artifactId>castor-maven-plugin</artifactId> <version>2.0</version> ... <dependencies> <dependency> <groupId>org.codehaus.castor</groupId> <artifactId>castor-codegen</artifactId> <version>1.3.2</version> </dependency> </dependencies> succeeds, so there seems some regression has occurred in castor-maven-plugin:2.1. Can we first try to solve this problem by introducing castor-codegen:1.3.2 as a dependency of castor-maven-plugin?
Hide
Permalink
Werner Guttmann added a comment - 02/Aug/11 9:44 AM

Can we first try to solve this problem by introducing castor-codegen:1.3.2 as a dependency of castor-maven-plugin?

If there's a regression issue with regards to the castor-maven-plugin, I will look into this in the context of this plugin.

Don't worry too much about all the other questions: if the issue is a problem with Castor (and still is a valid issue with release 1.3.2), we'll have a look. And if you really require a solution fast, and are not in a position to wait for a Castor 1.3.3 release, we can always push a snapshot release of Castor 1.3.3 to a Maven repo (for you to pick up).

But please do understand my request re: the separation of concerns as well.

Show
Werner Guttmann added a comment - 02/Aug/11 9:44 AM
Can we first try to solve this problem by introducing castor-codegen:1.3.2 as a dependency of castor-maven-plugin?
If there's a regression issue with regards to the castor-maven-plugin, I will look into this in the context of this plugin. Don't worry too much about all the other questions: if the issue is a problem with Castor (and still is a valid issue with release 1.3.2), we'll have a look. And if you really require a solution fast, and are not in a position to wait for a Castor 1.3.3 release, we can always push a snapshot release of Castor 1.3.3 to a Maven repo (for you to pick up). But please do understand my request re: the separation of concerns as well.
Hide
Permalink
Werner Guttmann added a comment - 02/Aug/11 10:10 AM - edited

First finding: can you please change dependency override section of your <plugin> definition as follows:

<dependencies>
   <dependency>
      <groupId>org.codehaus.castor</groupId>
      <artifactId>castor-codegen</artifactId>
      <version>1.3.2</version>
   </dependency>
   <dependency>
      <groupId>org.codehaus.castor</groupId>
      <artifactId>castor-xml-schema</artifactId>
      <version>1.3.2</version>
   </dependency>
</dependencies>

That should get you goinga against Castor 1.3.2, whilst I look into this dependency resolution problem.

Show
Werner Guttmann added a comment - 02/Aug/11 10:10 AM - edited First finding: can you please change dependency override section of your <plugin> definition as follows:
<dependencies>
   <dependency>
      <groupId>org.codehaus.castor</groupId>
      <artifactId>castor-codegen</artifactId>
      <version>1.3.2</version>
   </dependency>
   <dependency>
      <groupId>org.codehaus.castor</groupId>
      <artifactId>castor-xml-schema</artifactId>
      <version>1.3.2</version>
   </dependency>
</dependencies>
That should get you goinga against Castor 1.3.2, whilst I look into this dependency resolution problem.
Hide
Permalink
Werner Guttmann added a comment - 02/Aug/11 10:26 AM

In addition, found the problem related to the static initializer code; if you kindly raised a Castor Jira, I am in a position to provide and commit a patch.

Show
Werner Guttmann added a comment - 02/Aug/11 10:26 AM In addition, found the problem related to the static initializer code; if you kindly raised a Castor Jira, I am in a position to provide and commit a patch.
Hide
Permalink
Michiel Kalkman added a comment - 03/Aug/11 12:08 AM

Adding castor-xml-schema:1.3.2 as a dependency does help.

However, both castor-maven-plugin:2.0 and castor-maven-plugin:2.1 generate erroneous code. I will raise an issue at CASTOR.

Show
Michiel Kalkman added a comment - 03/Aug/11 12:08 AM Adding castor-xml-schema:1.3.2 as a dependency does help. However, both castor-maven-plugin:2.0 and castor-maven-plugin:2.1 generate erroneous code. I will raise an issue at CASTOR.
Hide
Permalink
Werner Guttmann added a comment - 29/Nov/11 4:35 PM

Fixing this within the Castor project, and making this available through a new release of this plugin.

Show
Werner Guttmann added a comment - 29/Nov/11 4:35 PM Fixing this within the Castor project, and making this available through a new release of this plugin.

People

  • Assignee:
    Werner Guttmann
    Reporter:
    Michiel Kalkman
Vote (0)
Watch (0)

Dates

  • Created:
    29/Jul/11 8:28 AM
    Updated:
    29/Nov/11 4:35 PM
    Resolved:
    29/Nov/11 4:35 PM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.