WARNING Coming Soon: Java 11 and JUnit 5

Technical Discussion
1

This effort has been discussed and underway for quite some time, and a candidate for updates required is finally ready in the java11 branch in the moqui-framework, moqui-runtime, example, mantle-usl, HiveMind, and PopCommerce components.

The main changes to be aware of, because they are not backward compatible, are the updates to require Java 11 (Java 8 no longer supported!) and to use Spock 2.1 with JUnit Platform (part of JUnit v5) which has some backward compatibility, but not with test suites so those will break unless updated. This is the reason for the java11 branch in the example, mantle-usl, HiveMind, and PopCommerce components that don’t otherwise need it.

For an example of the changes needed to build.gradle files and TestSuite classes to support JUnit Platform (v5), the mantle-usl component java11 branch may be helpful:

https://github.com/moqui/mantle-usl/compare/java11

Also included in this branch are updates to use Jetty 10 (which requires Java 11), Groovy 3, and support for Gradle 6+ (issues with Gradle 6 and 7 are resolved so they can now be used). These won’t impact most people as much, the changes for them are generally backward compatible.

The main reasons for this message are a warning about these changes coming up, and also a request for testing and validation with custom extensions and modifications that various are using. If these changes break anything that we can do something about then better to do so before these java11 branches are merged.

To try these branches in a local setup just do a pull all, then checkout the java11 branch in all. There are gradle tasks to make this easier:

$ gradle gitPullAll
$ gradle gitCheckoutAll -Pbranch=java11

Once this is done you should be able to run all tests (or however you test Moqui + your changes and extensions to it). If you run into issues, please use this topic to discuss them.

Unless there are issues that come up that delay this, I’d like to merge these in the next week or two.

2

Hi David, we have been adjusting some of our custom modules and so far it seems to be working.
Still need to update the testing, meanwhile I created a pull request for the moqui-hazelcast module in order to work with gradle 7.

3

We have found some issues when running the plusRuntimeWarTemp task, failing due to lack of a DuplicateStrategy. We have added a “warn” strategy to the copy task, so it does not fail, but we may get rid of the duplicates at all. The duplicates have 2 origins in our case:

  1. JAR files included in the librepo directory of the component. This can be resolved by adding an exclude for these directories in the components, as they are previously copied into the corresponding libs directory
  2. We have a module that in order to compile needs libraries already included in moqui-fop, so we added them as dependencies. This means the libraries are in both modules and hence will generate a duplication when generating the WAR file.

Is there a good way to add a dependency in gradle to use the libraries from another component (moqui-fop in this case) without adding them into de component’s lib directory?

4

Thank you Jens, your changes look good and are now merged in the moqui-hazelcast component.

5

I tried the addRuntime task and it worked fine, at least with the components that I have in place (which includes the moqui-fop component which has a librepo directory). Which line or command is it failing on, one of the copy commands?

For your question about #2, this is fairly standard in various build files so I’m not sure if this is what you’re asking about, but the build.gradle file in the moqui-fop component has an example of how to do with with the “:framework” module and the same pattern can be used for others. There are 2 parts to this:

  1. add a dependency: implementation project(':framework') under dependencies, line 51
  2. when copying dependencies from maven repo downloads to the lib directory subtract off the libraries from each dependency on another component or module, like this for the framework modeul: - project(':framework').configurations.runtimeClasspath - project(':framework').jar.archivePath on line 117
6

An update on this: I’m considering doing this merge as early as the end of this week, Friday the 22nd or Saturday the 23rd.

If anyone has any concerns or issues please reply here.

7

Without my local changes, it keeps failing, for both moqui-fop and moqui-wikitext.
The command line is simply ./gradlew addRuntime, and ./gradlew -version generates following output:

./gradlew -version

------------------------------------------------------------
Gradle 7.4.1
------------------------------------------------------------

Build time:   2022-03-09 15:04:47 UTC
Revision:     36dc52588e09b4b72f2010bc07599e0ee0434e2e

Kotlin:       1.5.31
Groovy:       3.0.9
Ant:          Apache Ant(TM) version 1.10.11 compiled on July 10 2021
JVM:          11.0.10 (BellSoft 11.0.10+9-LTS)
OS:           Mac OS X 12.1 aarch64

About #2, the problem is less about the libraries being in the module’s lib directory, but that once there, they also trigger a duplicate name while copying the jar files to generate the WAR file.

However, the changes are really simple so I will just generate a pull request to decide whether it should be included or not.

8

I’d say that before merging there should be a guide about what to do to migrate to the new version.

9

For notes on updating after the merge see the ReleaseNotes.md file and the initial post in this topic. The only non-backward compatible changes in the java11 branches are:

  1. Java 11+ now required (was Java 8+)
  2. JUnit Platform (JUnit 5) compatible TestSuite classes are now required (many JUnit 4 test classes work fine, but not TestSuite classes)
1 Like
10

Thanks for following up on this Jens. I wasn’t able to reproduce because I tried it with Gradle 5 and this only happens with newer versions like Gradle 7 (I didn’t try Gradle 6, may or may not happen there).

In this commit I added a variation on your changes:

I apologize for not merging your PR, was against the master branch instead of the java11 branch (so changed files included all changes in the java11 branch), and there were small changes in syntax and for the ecomponent directory to make it a bit more consistent and thorough.

11

Moqui now requires a Java 11 JDK to run.

The changes from the java11 branches have been merged into the master branches of moqui-framework, moqui-runtime, mantle-usl, example, PopCommerce, and HiveMind.