Support Java 9

[greenwoodma]

It turns out it's currently impossible to use the maven plugin under Java 9 due to the fact that JAXB is no longer part of the default accessible classes in the JVM. I've been unable to find a way of adding JAXB back via dependencies. The result is that if you have Java 9 you can't build any project which uses the OMTD Maven plugin. This is seriously problematic on Mac's where Java 8 is no longer available for download.

[reckart]

Try this: siom79/japicmp#177 (comment)

[greenwoodma]

Unfortunately that's basically what I'd already tried. While it doesn't throw any class not found exceptions the generated files now fail validation, whereas they pass under Java 8. As far as I know the files are identical which suggests there is an issue loading the XSD properly. I'll dig a little further to double check.

[greenwoodma]

so having now looked in more detail at the files produced under both Java 8 and Java 9 (attached) it seems that under Java 9 it's not writing the XML files correctly as most (but not all) of the elements are missing a namespace which then causes the validation to fail.

java8.txt
java9.txt

[reckart]

Interestingly ComponentDescriptorFactoryTest.testCreateComponent() produced the namespace prefixes correctly even when run under Java 10 - but the integration tests fail...

[greenwoodma]

I've just checked under Java 10 and for the component I was testing I get exactly the same output (i.e. missing prefix or no default namespace) as I do under Java 9. I've now tried three or four different combinations of libraries (com.sun..... or glassfish etc.) and all give identical results. I'm guessing fixing this is probably going to require rebuilding the JAXB classes representing the model under 2.3.0

[reckart]

@greenwoodma do you have any intuition why XmlUtil.write when called from ComponentDescriptorFactoryTest.testCreateComponent() produces proper namespace prefixes with even with newer JDKs (when adding explicit JAXB dependencies to the POM) but when it is called as part of the Maven integration test, the prefixes are missing?

[greenwoodma]

my guess would be something to do with the way the libs are added to the classpath being different when testing XmlUtil.write directly versus using it in the maven plugin. Unfortunately I can't see any obvious differences. I've also dug around in the JDK source code and can't see any obvious differences between Java 8 and 9/10 that seem related. At this point I'm kind of stumped.

[greenwoodma]

Okay, so I have no idea as yet how to fix this, or why it behaves differently under Java 8 versus Java 9, or test versus usage but.......

If you look at the generated sources for omtd-model then you'll notice that many of the elements don't specify namespace in the @xmlelement annotations. Where namespace is specified then it gets applied correctly when running under Java 9.

For example, I've attached the generated source for ComponentInfo (renamed to txt so I can attach it) and if you look at that file then you will see that resourceType doesn't have a namespace entry in the annotation and doesn't get a prefix under Java 9, but componentDistributionInfo does have the namespace entry and it gets the correct prefix.

So the question becomes how do we force JAXB when generating the classes to correctly add the namespace element to all annotations produced? Is this a config option when generating the sources or something that needs adding to the XSD?

ComponentInfo.txt

[greenwoodma]

Looking as the XSD files it seems elements that contain a ref attribute, pointing to the OMTD schema through the ms: namesapce, end up with the correct namespace definition in the generated Java source and the right prefix in the generated XML. I've tried naively adding extra ref elements but this tends to lead to an invalid XSD.

@pennyl67 any idea how we would ensure all elements within the XSD reference the OMTD schema correctly

[pennyl67]

@greenwoodma in the XSD there's a choice for qualified/unqualified namespace; I tried a test with rendering it unqualified (which means that the namespace doesn't have to be added in the XML file), but with elements that are referred to (i.e. reusable elements) unfortunately, this didn't work - the namespace needed to be declared to validate the files. I don't know if this helps clarify the issue, and I have no idea of how to change this.

[greenwoodma]

Thanks @pennyl67 . Yes it's all very strange. I did wonder about the qualified/unqualified option but didn't know exactly what it did.

As I say it's obviously related to the ref attribute somehow as this

<xs:element maxOccurs="unbounded" ref="ms:componentDistributionInfo"/>

works and gets the right prefix in generated files whereas

<xs:element fixed="component" name="resourceType">

ends up with the prefix missing when files are generated from the model. I tried altering this to include the ref attribute but that caused the file to be invalid.

[pennyl67]

Ok, we're in the following situation as far as I understand:

• I cannot enforce in the XSD not to ask for a namespace for all elements in the XML file (or at least I haven't found a way for this)
• All annotations when the XML is generated are rendered with a namespace in Java 8. But in Java 9 the namespace is added only for referred elements? This looks to me as something that needs to be forced with the Java. But we haven't figured how this can be configured. Is there a way of including an intermediate step after running the annotations to add the namespace? At least as a temporary solution until we figure out the source of the problem?

[reckart]

I cannot enforce in the XSD not to ask for a namespace for all elements in the XML file (or at least I haven't found a way for this)

I still do not understand why the prefix is important for validation in your setup. Neither the presence of the prefix nor the value of the prefix should matter during validation as long as the URIs are properly bound to whatever prefixes (or default namespace) are being used.

All annotations when the XML is generated are rendered with a namespace in Java 8. But in Java 9 the namespace is added only for referred elements? This looks to me as something that needs to be forced with the Java. But we haven't figured how this can be configured. Is there a way of including an intermediate step after running the annotations to add the namespace? At least as a temporary solution until we figure out the source of the problem?

I guess we need to take @courado on board here. It might help to create a package-info.java file i the right package to set some defaults for JAXB (cf. https://stackoverflow.com/questions/6895486/jaxb-need-namespace-prefix-to-all-the-elements).

[pennyl67]

I still do not understand why the prefix is important for validation in your setup. Neither the presence of the prefix nor the value of the prefix should matter during validation as long as the URIs are properly bound to whatever prefixes (or default namespace) are being used.

I think this is an inherent validation feature of XSD in general - this is why I tried the qualified/unqualified flag. But alas, it didn't work.

[greenwoodma]

Right, I have a fix!!!!

So it turns out that the underlying problem seems to be that when the generated model code is used from within a Maven plugin, running under Java 9, the package-info classes are ignored. This means you don't get the default namespace information. The fix is to tell XJC not to generate package-info and to instead internalise all the information with the classes. This is easy as you just add the -npa command line option within the pom.xml of omtd-model.

@courado I can make the fix on either master or development branch but we'll then need a new version of omtd-model pushing to maven central, so we can then update the OMTD maven plugin to produce a fixed version of that.

[antleb]

A quick comment: we are currently running everything using Java 8. I know it's outdated and we should upgrade to Java 9 or even Java 10 but this is not an easy process. Everything (including omtd-model) should be built with the new version of java, deployed in our test infrastructures, thoroughly tested and then officially release it.
Moving only one component to the new version of java is dangerous, and may lead bugs that will be hard to track down.

[reckart]

But please leave the target level at Java 8 :)

[greenwoodma]

Moving only one component to the new version of java is dangerous, and may lead bugs that will be hard to track down.

Agree completely, but this isn't about moving a component to Java 9, it about allowing people to use our code under Java 9. With the current version of omtd-model it's impossible to use the OMTD Share Maven plugin when running under Java 9 even if source and target are set to 1.8. All I'm asking is that we make it so that the generated class in omtd-model can be used under Java 9, although I agree they still need to be compiled under Java 8.