error when compiling LibreClinica with OpenJDK 11 (or greater)

[chae-reliatec]

When compiling LibreClinica with OpenJDK 11 (or greater) the following error occurs.

[ERROR] -----------------------------------------------------
[ERROR] realm =    plugin>org.codehaus.mojo:jaxb2-maven-plugin:2.3
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy

[chae-reliatec]

related to issue #172

[toskrip]

jaxb2-maven-plugin used to generate java classes from xsd scheme have issues with Java 9+. This is relevant for compiling LC not running it. It may be worth investigating if switch to jax-maven-plugin is feasible:

https://github.com/davidmoten/jax-maven-plugin

[rhe-reliatec]

I am fed up with switching back to a java-version released shortly after the end of the neolithicum, each time a have to perform a build.
It still does not compile with java11. As long as it does not compile, I'm not willing to say:
"The lc-develop-branch is ready to release."

[toskrip]

not sure about "ready to release" we have not seen the results from automated tests. Telco before release would be preferred. There we can also discuss if java11 building compatibility is requirement for next release.

[rhe-reliatec]

Sorry, there won't be any real automated test - I only can run automated tests with a simple teststudy. More would require that I have a server to that a can run testclients against, but I am just to incompetent to set up libreclinica on a linux-system I even to stupid to set up a linux system and on windows the famous and precious reliatec-test-framework does only run with small and simple things. So I give it up - no real tests.
But this is not the the point in this issue:
There is no build possible with a jdk newer than version 8.
The build-errors always say something about jaxb, which was retired with Java9.
Why don't you add some working dependencies in the pom?
I use jaxb till now - dependencies like:

javax.xml.bind
jaxb-api
${jaxb-version}



org.glassfish.jaxb
jaxb-runtime
${jaxb-version}
runtime

do the thing.
Do you need generating something by each build? Why? I generate my stuff once and copy it into my projects - works well.
I can remove the jaxb-stuff myself, but I am an incompetent person and may disturb some vital functions in the very vulnerable senile patient libreclinica.

[toskrip]

Originally the odm module was not part of the code repository but odm.jar was coming as an external dependency into to core module and parent project however it was available only from OC servers (which is situation that we wanted to avoid). I brought odm module into the repository. I proposed that it is not necessary to version control generated java classes (why to version something that is generated, better version only the schema). This was agreed upon and thus odm.jar is created based on schema during build.

Note: the other reason why this solution was chosen was that OC does store the generated classes in separate repository from where they are building odm.jar for their dependency management purposes. However there is no license information available and we wanted to avoid potential license issues.

It should possible to make the classes generation work on newer java but it has to be examined carefully (new version of current jaxb2-maven-plugin should support it, but likely jakartaee namespace changes are required as well). Complaining about situation is not helpful, also you don't have to break things in working branch... just create a new branch and try to develop solution that works for java11 when it is a priority.

[rhe-reliatec]

I understand not a single word of this.
What is odm - the clinical-data exported as the 'odm.xml' and 'odm.jar' the generated java-model for doing this?
Why not generate once, put it in the repository and done ...? odm has a version number it will never change.

[toskrip]

As you say, odm module represents the generated java model for CDISC ODM standard. However it is not true that it will never change. We have EDC system vendor specific extensions that can change depending on new features in EDC system. And also, ODM as any other standard, it is still being developed further (e.g. ODM 2.0 is currently under development at CDISC). This means that every time we change the xsd defining the ODM with vendor specific extensions the underlying java classes need to be regenerated.

[rhe-reliatec]

I still don't understand - maybe I am to simply-minded for this...
There is the 'use-case' export-data-as odm x.y.z in libreclinica. So it exports the stored-data in a xml-file with OpenClinica extensions. I frequently pushed that button lately.
Is there another-use case for odm? Where are the generated classes used? Must LibreClinica be build the next couple of years with java 8, because there may be a 'export-data as odm xx.yy.zz' use case some day far in the feature?
By the way you self-assigned this on 26 May to you.

[toskrip]

Not just export, study metadata is using this model, REST web services are using this model, I think also form printing is using it. I already mentioned to you that this was decision that was done together with rest of team long time ago (based on my proposal). Feel free to take over the ticket if you have better implementation.