Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move to JUnit 5 and Gradle 7 #495

Closed
wants to merge 3 commits into from

Conversation

MohammadAlHajj
Copy link
Contributor

Dear Mr. Jones
please find the connected commits to the below repos:

  • mantle-usl
  • moqui-framework
  • moqu-runtime

the goal of these commits is to move to Gradle 7.2 and to Junit 5

gradle 7:
changes need some

  • more testing since i don't know if any more dependencies need to be changed to "java-library"'s 'api' dependency type or kept at gradle's built-in implementation type.
  • These changes rely on the user's projects and which dependencies need their internals exposed to the user's projects.
  • I also solved the known issue (noted in runtime > base-component > webroot > gradel.build):
    How to handle deprecated message related to Gradle 6.0 and the gradle-js-plugin ? eriwen/gradle-js-plugin#168
    by doing:
    Gradle 6.0.1 Build Failed eriwen/gradle-js-plugin#177 (comment)
  • NOTE: the above project is probably dead and i highly advise the maintainer with the sufficient knowledge to find a replacement.... storing jars in the repo is obviously not an acceptable permanent solution
  • Moving to gradle 7 allows the use of the newest Kotlin compiler in our projects and opens the door for moving to Java 11 or possibly java 17 whenit is released

JUnit5

  • changes are none-intrusive since applying the new Jupiter and Vintage engines together allows both JUnit 4 and 5 tests to be run simultaneously..... It also separates the result of junit 4 tests into more readable chunks in Intellij (on running "gradle test"). Each test is now part of a subtree with the containing class as the new root of the test group
  • Please note that i changed " ignoreFailures = true" since moqui (framework and usl) already has failing tests (on my project) and this blocks the execution of any further tests found in the user's module

For any modification to the commit or for further information, please contact me on Mohammad_Al-Hajj@hotmail.com

Mohammad Al-Hajj added 2 commits August 27, 2021 19:07
-All test tasks now have "ignoreFailures = true" since some stock tests are failing already and blocking the custom tests of the user
@jonesde
Copy link
Member

jonesde commented Sep 6, 2021

Thank you Mohammad, this will be helpful. A few weeks ago I was working on updating to Groovy 3, which requires an update to Spock to a version that requires JUnit 5, and I was having trouble getting those working before running out of time, so this should be helpful for the Groovy 3 update effort as well.

On the time topic, my time is pretty limited for the next few weeks so it may be some time before I work on this. I plan to do these sorts of changes as part of the 'java11' branch of moqui-framework so that we can get a few of these big version updates in at the same time, especially because a few are not backward compatible.

In the webroot component build.gradle in moqui-runtime IMO we need to find an alternative sooner than later, and I'd prefer that over another jar variant that we maintain (we already do that for Bitronix), even if it means that we only do simple JS and CSS file combining (just concatenate) and live without the minify.

@MohammadAlHajj
Copy link
Contributor Author

Thank you for the reply David. The next major LTS version of Java (17) will be released on 2021/09/14. Might i suggest that we wait and directly upgrade to that instead of Java 11.

Regarding the webroot gradle js and css minify, here are some solutions that the users of the eriwin project migrated to:

these solutions are not mine nor do i have enough web knowledge to compare their efficiency

@jonesde
Copy link
Member

jonesde commented Sep 7, 2021

It will be a long time after Java 17 is released before we require it in Moqui. Just like Java 11 now, the intent will be to support it for some time while waiting for libraries and infrastructure to catch up (including operating systems, hosting service default images, etc). Part of the community feedback on this includes things like versions of Java supported on all sorts of platforms from AWS Elastic Beanstalk and Container Service to IBM iSeries.

The main impact of this is we can't use new language features until the newer version of Java is required for Moqui, and until fairly recently there were reasons we could not update to Java 11 without breaking things for some Moqui users who told us about that in community feedback.

@MohammadAlHajj
Copy link
Contributor Author

Hello David, any updates?

@jonesde
Copy link
Member

jonesde commented Dec 29, 2021

Nope, no updates, and this could require a fair amount of work. As with most things on my mile long to do list (most of which I'm not interested in), this will get done when I care about it enough AND have sufficient free time and energy for it, or when a client pays to prioritize.

This PR should not go in as-is and I couldn't give an ETA. At some point updating Java, Groovy, Spock, Gradle, etc will become a priority for some reason, but for now other features and such are higher priorities.

@MohammadAlHajj
Copy link
Contributor Author

No worries.... I can work on this myself if you wish, but my pace will be probably the same as yours.

Out of subject, but how can I ask questions like the ones on the mailing list. I currently have a stack of questions/helper tools/feedback/(recommendations?!) i would like to share.

@jonesde
Copy link
Member

jonesde commented Dec 29, 2021

Out of subject, but how can I ask questions like the ones on the mailing list. I currently have a stack of questions/helper tools/feedback/(recommendations?!) i would like to share.

The mailing list is a fine place, the new forums even better (forum.moqui.org).

@jonesde
Copy link
Member

jonesde commented May 17, 2022

This is complete as of the merge of the 'java11' branch.

@jonesde jonesde closed this May 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants