Details

    • Improvement
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • Version 5.1.0
    • Version 5.1.1
    • None
    • None

    Description

      https://github.com/javaparser/javaparser/releases/tag/javaparser-parent-3.24.3 seems to have breaking changes. This is tagged 3.24.3 but that release seems to have failed and a newer release 3.24.4 was made.

      The xmlbeans build fails with this version. It appears some generated code appears in Java files whose name does match the name of the class (case sensitivity issues).

      We could fix the tests so that the build succeeds but the question is would users who use XMLBeans also hit similar issues with their XSD to Java code generation?

      Attachments

        Activity

          pakeller Peter Keller added a comment -

          I'd be interested in taking a closer look at this, but I haven't been able to reproduce the failure. What I tried was:

          git checkout 97c8393

          I then changed every reference to version 3.24.3 to 3.24.4 in that commit, and did:

          ./gradlew clean
          ./gradlew test

          which worked.

          (This was on Linux: openSUSE Leap 15.3)

          Have I misunderstood what is going on?

          FWIW, I have also tried switching JavaParser from 3.24.2 to 3.24.4 in my main project that uses XMLBeans (this is using release 5.1.0). The resulting Java code compiles fine, I will run some tests later today. Eyeballing the generated code, it seems that the only difference that the switch in JavaParser version makes for me is in the order in which some of the methods appear in the generated Java source.

          pakeller Peter Keller added a comment - I'd be interested in taking a closer look at this, but I haven't been able to reproduce the failure. What I tried was: git checkout 97c8393 I then changed every reference to version 3.24.3 to 3.24.4 in that commit, and did: ./gradlew clean ./gradlew test which worked. (This was on Linux: openSUSE Leap 15.3) Have I misunderstood what is going on? FWIW, I have also tried switching JavaParser from 3.24.2 to 3.24.4 in my main project that uses XMLBeans (this is using release 5.1.0). The resulting Java code compiles fine, I will run some tests later today. Eyeballing the generated code, it seems that the only difference that the switch in JavaParser version makes for me is in the order in which some of the methods appear in the generated Java source.
          pj.fanning PJ Fanning added a comment -

          xmlbeans won't build on my Mac when javaparser 3.24.4 is used (while it builds fine with javaparser 3.24.2).

          ```
          > Task :compileTestJava
          /Users/pj.fanning/svn/xmlbeans/build/generated/sources/sSIMPLE/test/java/noNamespace/impl/ResultDocument2Impl.java:20: error: class RESULTDocument2Impl is public, should be declared in a file named RESULTDocument2Impl.java
          public class RESULTDocument2Impl extends org.apache.xmlbeans.impl.values.XmlComplexContentImpl implements noNamespace.RESULTDocument2 {
          ^
          /Users/pj.fanning/svn/xmlbeans/build/generated/sources/sSIMPLE/test/java/noNamespace/impl/RESULTDocumentImpl.java:20: error: class ResultDocumentImpl is public, should be declared in a file named ResultDocumentImpl.java
          public class ResultDocumentImpl extends org.apache.xmlbeans.impl.values.XmlComplexContentImpl implements noNamespace.ResultDocument {
          ^
          /Users/pj.fanning/svn/xmlbeans/build/generated/sources/sSIMPLE/test/java/noNamespace/ResultDocument2.java:22: error: class RESULTDocument2 is public, should be declared in a file named RESULTDocument2.java
          public interface RESULTDocument2 extends org.apache.xmlbeans.XmlObject {
          ^
          /Users/pj.fanning/svn/xmlbeans/build/generated/sources/sSIMPLE/test/java/noNamespace/RESULTDocument.java:22: error: class ResultDocument is public, should be declared in a file named ResultDocument.java
          public interface ResultDocument extends org.apache.xmlbeans.XmlObject {
          ^
          Note: Some input files use or override a deprecated API.
          Note: Recompile with -Xlint:deprecation for details.
          Note: Some input files use unchecked or unsafe operations.
          Note: Recompile with -Xlint:unchecked for details.
          4 errors
          ```

          I've changed the javaparser version in svn and so far the CI build seems happy.

          I'll see if a new checkout of xmlbeans fixes the build on my machine - maybe something is left behind from a previous build that `./gradlew clean` does not remove.

          pj.fanning PJ Fanning added a comment - xmlbeans won't build on my Mac when javaparser 3.24.4 is used (while it builds fine with javaparser 3.24.2). ``` > Task :compileTestJava /Users/pj.fanning/svn/xmlbeans/build/generated/sources/sSIMPLE/test/java/noNamespace/impl/ResultDocument2Impl.java:20: error: class RESULTDocument2Impl is public, should be declared in a file named RESULTDocument2Impl.java public class RESULTDocument2Impl extends org.apache.xmlbeans.impl.values.XmlComplexContentImpl implements noNamespace.RESULTDocument2 { ^ /Users/pj.fanning/svn/xmlbeans/build/generated/sources/sSIMPLE/test/java/noNamespace/impl/RESULTDocumentImpl.java:20: error: class ResultDocumentImpl is public, should be declared in a file named ResultDocumentImpl.java public class ResultDocumentImpl extends org.apache.xmlbeans.impl.values.XmlComplexContentImpl implements noNamespace.ResultDocument { ^ /Users/pj.fanning/svn/xmlbeans/build/generated/sources/sSIMPLE/test/java/noNamespace/ResultDocument2.java:22: error: class RESULTDocument2 is public, should be declared in a file named RESULTDocument2.java public interface RESULTDocument2 extends org.apache.xmlbeans.XmlObject { ^ /Users/pj.fanning/svn/xmlbeans/build/generated/sources/sSIMPLE/test/java/noNamespace/RESULTDocument.java:22: error: class ResultDocument is public, should be declared in a file named ResultDocument.java public interface ResultDocument extends org.apache.xmlbeans.XmlObject { ^ Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. 4 errors ``` I've changed the javaparser version in svn and so far the CI build seems happy. I'll see if a new checkout of xmlbeans fixes the build on my machine - maybe something is left behind from a previous build that `./gradlew clean` does not remove.
          pj.fanning PJ Fanning added a comment -

          Even a fresh checkout on my Mac runs into same issue described above.

          pj.fanning PJ Fanning added a comment - Even a fresh checkout on my Mac runs into same issue described above.
          pakeller Peter Keller added a comment -

          Some time ago, I used to develop jointly on Linux and OS X (as it was then), and I remember running into something like this issue. It wasn't with XMLBeans specifically, but my own code, and as I remember I ended up with two Java package names that differed only by case. Linux was happy, but OS X not.

          As I am sure you know, on OS X/macOS, the filesystem is by default case-insensitive but case-aware. It looks like the Java compiler expects the classname and containing filename to match by case even under those circumstances. Looking at the first error, where the file on your Mac is:

          build/generated/sources/sSIMPLE/test/java/noNamespace/impl/ResultDocument2Impl.java

          I get the following file on Linux:

          build/generated/sources/sSIMPLE/test/java/noNamespace/impl/RESULTDocument2Impl.java

          so the Java compiler is happy in my hands.

          Unfortunately, I don't have access to a Mac any longer and the breakage doesn't affect Linux, so it is hard for me to look into this. I wonder if you created a new partition and filesystem on your Mac and selected the case-sensitive option, whether the XMLBeans tests would work on that filesystem, although that isn't a proper fix for this breakage of course.

          pakeller Peter Keller added a comment - Some time ago, I used to develop jointly on Linux and OS X (as it was then), and I remember running into something like this issue. It wasn't with XMLBeans specifically, but my own code, and as I remember I ended up with two Java package names that differed only by case. Linux was happy, but OS X not. As I am sure you know, on OS X/macOS, the filesystem is by default case-insensitive but case-aware. It looks like the Java compiler expects the classname and containing filename to match by case even under those circumstances. Looking at the first error, where the file on your Mac is: build/generated/sources/sSIMPLE/test/java/noNamespace/impl/ResultDocument2Impl.java I get the following file on Linux: build/generated/sources/sSIMPLE/test/java/noNamespace/impl/RESULTDocument2Impl.java so the Java compiler is happy in my hands. Unfortunately, I don't have access to a Mac any longer and the breakage doesn't affect Linux, so it is hard for me to look into this. I wonder if you created a new partition and filesystem on your Mac and selected the case-sensitive option, whether the XMLBeans tests would work on that filesystem, although that isn't a proper fix for this breakage of course.
          pj.fanning PJ Fanning added a comment -

          I get the correct names of the files and classes when javaparser 3.24.2 is used:

          • ResultDocument and ResultDocumentImpl
          • RESULTDocument2 and RESULTDocument2Impl

          Something about javaparser 3.24.4 means that the class names and java file names get mixed up. The Java class names are the same as when I run with javaparser 3.24.2 but the file names get the opposite Result/RESULT prefix from what they should.

          pj.fanning PJ Fanning added a comment - I get the correct names of the files and classes when javaparser 3.24.2 is used: ResultDocument and ResultDocumentImpl RESULTDocument2 and RESULTDocument2Impl Something about javaparser 3.24.4 means that the class names and java file names get mixed up. The Java class names are the same as when I run with javaparser 3.24.2 but the file names get the opposite Result/RESULT prefix from what they should.
          pj.fanning PJ Fanning added a comment -

          This gets stranger still. If I run with javaparser 3.24.4 and change build.gradle so the org.apache.xmlbeans.impl.tool.SchemaCompiler is run with `-verbose` instead of `-quiet`, then the generated source code is correct and compiles without issue.

          pj.fanning PJ Fanning added a comment - This gets stranger still. If I run with javaparser 3.24.4 and change build.gradle so the org.apache.xmlbeans.impl.tool.SchemaCompiler is run with `-verbose` instead of `-quiet`, then the generated source code is correct and compiles without issue.

          People

            pj.fanning PJ Fanning
            pj.fanning PJ Fanning
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: