Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the Gradle wrapper to version 9.4.1 and adds the JUnit Platform Launcher dependency to the jme3-screenshot-tests module. The reviewer suggested changing the dependency scope from testRuntimeOnly to runtimeOnly to ensure the launcher is transitively available to other modules that depend on this project as a test framework.
| implementation 'com.aventstack:extentreports:5.1.2' | ||
| implementation platform('org.junit:junit-bom:5.9.1') | ||
| implementation 'org.junit.jupiter:junit-jupiter' | ||
| testRuntimeOnly 'org.junit.platform:junit-platform-launcher' |
There was a problem hiding this comment.
In Gradle 9, the junit-platform-launcher is required at runtime for executing JUnit 5 tests. Since jme3-screenshot-tests acts as a test framework for other modules (providing base classes in src/main), changing this to runtimeOnly ensures the launcher is transitively available to all consumers of this module. This avoids the need to manually add the launcher to every module's dependencies and ensures consistent test execution across the project.
runtimeOnly 'org.junit.platform:junit-platform-launcher'
|
Oh, it looks like we need to be running jdk 17+ for gradle 9. We need to first update some other dependencies... Trying to untangle the order of operations of all this. @riccardobl we will need your PR to upgrade android build tools. |
|
The latest stable release of the JME SDK is "3.8.0-stable-sdk1", which was based on Netbeans 25. Netbeans didn't really support Gradle v9 prior to Netbeans 27. I think the first step in untangling is to decide whether the JME SDK is still important. If it is, then bring the SDK up to date and publish a stable release. |
There is the pre-release that is on Netbeans 28. While that needs a re-release to be marked as done, it is in the near future. But in general I don't think you should consider the SDK as a blocker in this regard. For the end user the SDK will satisfy every point regardless the Gradle version used in jME itself. Only thing a SDK user would struggle with is building the latest jME version itself within the engine but I doubt there are many people doing this. All the SDK features work regardless of jME Gradle version. |
3 participants
#2695
@stephengold mentioned in #2641 that the sdk would block gradle 9, but I see that it is already on netbeans 28 and gradle 9 now.
So it's not a problem for this now, but do we still block jmonkey core on the sdk? Wondering if there is an agreed on policy.