The mrJar Plugin v0.0.16 has been released — JPMS Modules Made Easy

I deleted all com.lingocoder files, updated Eclipse Buildship to Buildship 3.1.3.v20191117-2045, then I tried the test again and I have exactly the same behavior.
It does not change anything if I try to do a Gradle Test manually in Run Configurations.

Here is the Eclipse log:

!ENTRY org.eclipse.buildship.core 2 3 2019-12-03 14:20:52.962
!MESSAGE Launch Gradle tests failed due to an error connecting to the Gradle build.
!STACK 0
org.gradle.tooling.TestExecutionException: Could not execute tests using Gradle distribution ‘https://services.gradle.org/distributions/gradle-6.0.1-all.zip’.
at org.gradle.tooling.internal.consumer.ExceptionTransformer.transform(ExceptionTransformer.java:49)
at org.gradle.tooling.internal.consumer.ExceptionTransformer.transform(ExceptionTransformer.java:29)
at org.gradle.tooling.internal.consumer.ResultHandlerAdapter.onFailure(ResultHandlerAdapter.java:43)
at org.gradle.tooling.internal.consumer.async.DefaultAsyncConsumerActionExecutor$1$1.run(DefaultAsyncConsumerActionExecutor.java:62)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
at java.base/java.lang.Thread.run(Thread.java:834)
at org.gradle.tooling.internal.consumer.BlockingResultHandler.getResult(BlockingResultHandler.java:46)
at org.gradle.tooling.internal.consumer.DefaultTestLauncher.run(DefaultTestLauncher.java:115)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.eclipse.buildship.core.internal.workspace.ConnectionAwareLauncherProxy.invokeRun(ConnectionAwareLauncherProxy.java:102)
at org.eclipse.buildship.core.internal.workspace.ConnectionAwareLauncherProxy.invoke(ConnectionAwareLauncherProxy.java:92)
at com.sun.proxy.$Proxy71.run(Unknown Source)
at org.eclipse.buildship.core.internal.launch.RunGradleJvmTestLaunchRequestJob$RunLaunchRequestJob.executeLaunch(RunGradleJvmTestLaunchRequestJob.java:128)
at org.eclipse.buildship.core.internal.launch.RunGradleJvmTestLaunchRequestJob$RunLaunchRequestJob.executeLaunch(RunGradleJvmTestLaunchRequestJob.java:89)
at org.eclipse.buildship.core.internal.launch.BaseLaunchRequestJob.executeLaunch(BaseLaunchRequestJob.java:66)
at org.eclipse.buildship.core.internal.launch.BaseLaunchRequestJob.runInToolingApi(BaseLaunchRequestJob.java:42)
at org.eclipse.buildship.core.internal.launch.BaseLaunchRequestJob.runInToolingApi(BaseLaunchRequestJob.java:34)
at org.eclipse.buildship.core.internal.operation.ToolingApiJob$1.runInToolingApi(ToolingApiJob.java:54)
at org.eclipse.buildship.core.internal.operation.DefaultToolingApiOperationManager$WorkspaceRunnableAdapter.run(DefaultToolingApiOperationManager.java:58)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2295)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2322)
at org.eclipse.buildship.core.internal.operation.DefaultToolingApiOperationManager.run(DefaultToolingApiOperationManager.java:39)
at org.eclipse.buildship.core.internal.operation.ToolingApiJob.run(ToolingApiJob.java:65)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: org.gradle.api.tasks.testing.TestExecutionException: No matching tests found in any candidate test task.
Requested tests:
Test class mr.jar.graou74.LibraryTest
at org.gradle.tooling.internal.provider.runner.TestExecutionResultEvaluator.evaluate(TestExecutionResultEvaluator.java:68)
at org.gradle.tooling.internal.provider.runner.TestExecutionRequestActionRunner.run(TestExecutionRequestActionRunner.java:52)
at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
at org.gradle.launcher.exec.BuildOutcomeReportingBuildActionRunner.run(BuildOutcomeReportingBuildActionRunner.java:63)
at org.gradle.tooling.internal.provider.ValidatingBuildActionRunner.run(ValidatingBuildActionRunner.java:32)
at org.gradle.launcher.exec.BuildCompletionNotifyingBuildActionRunner.run(BuildCompletionNotifyingBuildActionRunner.java:39)
at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner$3.call(RunAsBuildOperationBuildActionRunner.java:51)
at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner$3.call(RunAsBuildOperationBuildActionRunner.java:45)
at org.gradle.internal.operations.DefaultBuildOperationExecutor$CallableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:416)
at org.gradle.internal.operations.DefaultBuildOperationExecutor$CallableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:406)
at org.gradle.internal.operations.DefaultBuildOperationExecutor$1.execute(DefaultBuildOperationExecutor.java:165)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:250)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:158)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:102)
at org.gradle.internal.operations.DelegatingBuildOperationExecutor.call(DelegatingBuildOperationExecutor.java:36)
at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner.run(RunAsBuildOperationBuildActionRunner.java:45)
at org.gradle.launcher.exec.InProcessBuildActionExecuter$1.transform(InProcessBuildActionExecuter.java:50)
at org.gradle.launcher.exec.InProcessBuildActionExecuter$1.transform(InProcessBuildActionExecuter.java:47)
at org.gradle.composite.internal.DefaultRootBuildState.run(DefaultRootBuildState.java:78)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:47)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:31)
at org.gradle.launcher.exec.BuildTreeScopeBuildActionExecuter.execute(BuildTreeScopeBuildActionExecuter.java:42)
at org.gradle.launcher.exec.BuildTreeScopeBuildActionExecuter.execute(BuildTreeScopeBuildActionExecuter.java:28)
at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:78)
at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:52)
at org.gradle.tooling.internal.provider.SubscribableBuildActionExecuter.execute(SubscribableBuildActionExecuter.java:59)
at org.gradle.tooling.internal.provider.SubscribableBuildActionExecuter.execute(SubscribableBuildActionExecuter.java:36)
at org.gradle.tooling.internal.provider.SessionScopeBuildActionExecuter.execute(SessionScopeBuildActionExecuter.java:68)
at org.gradle.tooling.internal.provider.SessionScopeBuildActionExecuter.execute(SessionScopeBuildActionExecuter.java:38)
at org.gradle.tooling.internal.provider.GradleThreadBuildActionExecuter.execute(GradleThreadBuildActionExecuter.java:37)
at org.gradle.tooling.internal.provider.GradleThreadBuildActionExecuter.execute(GradleThreadBuildActionExecuter.java:26)
at org.gradle.tooling.internal.provider.ParallelismConfigurationBuildActionExecuter.execute(ParallelismConfigurationBuildActionExecuter.java:43)
at org.gradle.tooling.internal.provider.ParallelismConfigurationBuildActionExecuter.execute(ParallelismConfigurationBuildActionExecuter.java:29)
at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:60)
at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:32)
at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:55)
at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:41)
at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:48)
at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:32)
at org.gradle.launcher.daemon.server.exec.ExecuteBuild.doBuild(ExecuteBuild.java:68)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:37)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
at org.gradle.launcher.daemon.server.exec.WatchForDisconnection.execute(WatchForDisconnection.java:39)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
at org.gradle.launcher.daemon.server.exec.ResetDeprecationLogger.execute(ResetDeprecationLogger.java:27)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
at org.gradle.launcher.daemon.server.exec.RequestStopIfSingleUsedDaemon.execute(RequestStopIfSingleUsedDaemon.java:35)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.create(ForwardClientInput.java:78)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.create(ForwardClientInput.java:75)
at org.gradle.util.Swapper.swap(Swapper.java:38)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput.execute(ForwardClientInput.java:75)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
at org.gradle.launcher.daemon.server.exec.LogAndCheckHealth.execute(LogAndCheckHealth.java:55)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
at org.gradle.launcher.daemon.server.exec.LogToClient.doBuild(LogToClient.java:63)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:37)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
at org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment.doBuild(EstablishBuildEnvironment.java:82)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:37)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy$1.run(StartBuildOrRespondWithBusy.java:52)
at org.gradle.launcher.daemon.server.DaemonStateCoordinator$1.run(DaemonStateCoordinator.java:297)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
at java.base/java.lang.Thread.run(Thread.java:834)

The trace of what happens when I do a Run with JUnit Test:

Error occurred during initialization of boot layer
java.lang.module.FindException: Module javafx.graphics not found, required by myApplication

I’m not sure how much it matters. But the version of Buildship I’m running is 3.1.4.v20191121-2249-s. I think the -s on the end of the version string means Snapshot. I got that version by accepting an autoupdate that Eclipse prompted me for a couple days ago, if I recall correctly

I was able to reproduce that Module not found error, @Graou74. But I was also able to recover from that by first running either the :eclipse task beforehand or the :test or :check tasks (or their context menu equivalent: Run As Gradle Test).

In this recording I start with pretty much a clean slate. You can observe where I delete the project and then reimport it…

Then I do the steps you did in your vid with Run As Gradle Test. I also show the before and after of Gradle — Refresh Gradle Project and running the :eclipse task. Please pay close attention to the Eclipse Java Build Path in the recording. Compare what you see in the recording with what you see on your own machine.

You’ll observe that at first, there is only the JDK modules in the module path. Then after the :eclipse task, all the declared depenencies are on the module path. Doing Run As Gradle Test has the exact same effect of adding the dependencies to the module path.

I ran as a Gradle test a number of consecutive times in succession. And each time, it ran as expected. You’ll also see where I edited both Library.java and LibraryTest.java with success.

Then for good measure, I also ran the JavaFX class — both with Eclipse’s Run As Java Application and from the Gradle Tasks view with the :run task. The error you will see on the first run is because I forgot to pass in the argument the application expects. After I remembered to do that: SUCCESS.

I’m stumped as to what the problem is, @Graou74. I hesitate to ask whether it might be something Mac related. Because that would come as a huge surprise to me. So I have to assume that it is an as-yet Unidentified Failure Occurring somewhere in mrJar.

One other thing you could try as a long shot— if you have the patience — is…

  1. From the command line: ./gradlew --gradle-user-home=<a.different.folder> --refresh-dependencies test

    • that will take a few minutes, because it will redownload the wrapper, its dependencies plus all the project’s dependencies
  2. Close, delete and reimport your project into Eclipse

    • before you reimport, delete the .gradle, build and .settings folders plus the .classpath and .project files (like I do in the recording)
    • when you reimport, use in the corresponding field of the import wizard, whatever folder you specified as --gradle-user-home=<a.different.folder>

I am committed to eventually figuring this out, @Graou74 so that you don’t have to.

Whenever you have a spare five minutes, please can you…

  1. Edit your settings.gradle to this

    ...
    plugins {
    id "com.gradle.enterprise" version "3.1"
    }
    rootProject.name = 'Graou74'
    
  2. Add this block to the bottom of your build.gradle

    ...
    
    buildScan {
        termsOfServiceUrl = 'https://gradle.com/terms-of-service'
        termsOfServiceAgree = 'yes'
    } 
    
  3. Open Run — Run Configurations — Gradle Test — LibraryTest — Project Settings

  4. Run as Gradle Test should dump a ton of output to the console and the stack trace will probably go to Eclipse’s Error log

    • please copy all of that to file(s)?
    • upload them to me?

TIA

Finally, I have reproduced the issue in Linux, @Graou74. So there is no longer any need for you to do any of those those reimport steps. I’m on the case.

49/5000

Ok, it’s an OS problem. good luck

More of an OP problem actually :blush: The failure was caused by a --cmdline-option="/had/a/file/path/within/quotes". Windows seemed to be happy with such a quoted path. Still not 100% sure why they’re a no-go on *nix.

With the quotes, I got the exact same failure outcomes on Linux that you got on Mac.

Removing the quotes, fixed the problem on Linux. So hopefully you’ll have the same working result now on Mac.

Please observe very closely the part of the attached recording where I show Eclipse’s Java Build Path after I run the :eclipse task.

It’s important to remember that running that task triggers Eclipse Modulefication. It, :test and Run As Gradle Test all have the same effect of adding the dependencies to the module path. If you forget to do one of those three, then you should expect some kind of JPMS module-related error.

Notice also that I point out that yellow and black yield sign that Eclipse alerts you to on the Java Build Path dialog? That’s also pretty important. After you do the Eclipse Modulefication, you should check that property page and click the Apply button to get the module path to take effect. Again though: when the jpmsOpts property is not used, that step can be skipped.

Please let me know if it still isn’t working on Mac? And I’ll go back to the drawing board.

??? :confused: ???

Make a zip of your project available, and I see if it works after import into Eclipse. Sorry but I can not do more, I’m on a problem that requires all my attention.

lingocoder.graou74.mr.fixit.0.zip (168.3 KB)

I hope this helps?

No sorry, it’s even worse, now the test fails right away while before the first one was working.

I just downloaded the project, removed the com.lingocoder plugin from the Gradle cache, imported the project into Eclipse, made a “Refresh Gradle Project” and then “Run As / 1 Gradle test”.

It’s in such moments that I tell myself that I love this job.

Working Directory: /Users/fbmac/Documents/_projets/Zulu-java-11-33/Ondine/Application/Graou74

Gradle user home: /Users/fbmac/.gradle

Gradle Distribution: Gradle wrapper from target build

Gradle Version: 6.0.1

Java Home: /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home

JVM Arguments: None

Program Arguments: None

Build Scans Enabled: false

Offline Mode Enabled: false

Tests: mr.jar.graou74.LibraryTest

Task :eclipseClasspath

Task :compileJava

Task :processResources NO-SOURCE

Task :classes

Task :compileJava10Java NO-SOURCE

Task :processJava10Resources NO-SOURCE

Task :java10Classes UP-TO-DATE

Task :compileJava11Java NO-SOURCE

Task :processJava11Resources NO-SOURCE

Task :java11Classes UP-TO-DATE

Task :compileJava12Java NO-SOURCE

Task :processJava12Resources NO-SOURCE

Task :java12Classes UP-TO-DATE

Task :compileJava9Java NO-SOURCE

Task :processJava9Resources NO-SOURCE

Task :java9Classes UP-TO-DATE

Task :jar

Task :compileTestJava

warning: [options] --add-opens has no effect at compile time

1 warning

Task :processTestResources

Task :testClasses

Task :test FAILED

Error occurred during initialization of boot layer

java.lang.module.FindException: Module java.lang.module.InvalidModuleDescriptorException: not found

FAILURE: Build failed with an exception.

  • What went wrong:

Execution failed for task ‘:test’.

Process ‘Gradle Test Executor 2’ finished with non-zero exit value 1

  • Try:

Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.

Use ‘–warning-mode all’ to show the individual deprecation warnings.

See https://docs.gradle.org/6.0.1/userguide/command_line_interface.html#sec:command_line_warnings

BUILD FAILED in 3s

6 actionable tasks: 6 executed

However “Run As / 1 Gradle test” works now. It fails the first time but after it works very well.

I’m very sorry that you’re experiencing some frustration, @Graou74. I empathize with you completely. Believe me.

Transcribing that as these steps…

  1. remove the com.lingocoder plugin from the Gradle cache
  2. import the project into Eclipse
  3. execute “Refresh Gradle Project”
  4. and then “Run As / 1 Gradle test”

Then Step 3 is not only unnecessary, it might also be the reason the test fails the first time.

I say that it is unnecessary, because the effect of Step 2 (import the project) is to already give you a fresh project. Step 1 could be (should be?) avoided too, if you add --refresh-dependencies to the Program Arguments field during initial import.

I say it causes the test to fail, because Refresh Gradle Project undoes/removes the module path.

What exactly is the specific reason that you need to to Refresh Gradle Project immediately after the initial import?

For a fresh import the steps should be…

  1. Import the project into Eclipse

    • during this process, consider optionally adding --refresh-dependencies to the Buildship wizard’s Program Arguments field
  2. Execute the :eclipse task

    • that has the same effect as Run As Gradle Test and the :test task, but unlike those two, it allows you to do Step 3
  3. Open the project’s properties dialog

    • Go to the Java Build Path properties tab
    • Notice the notification in the title bar (Not all modules could be found. Click Apply to synchronize), and click the Apply button to synchronize the module path
  4. Execute the :test task

    • or alternatively, do Run As Gradle Test - six of one, half a dozen of the other (i.e.: same difference)
    • or alternatively again, executing the :check task is another option that has the same Eclipse Modulefication effect as the other three options

After you import the project initially, then all you need to do from then on is go straight to Step 4. As long as you do not do Gradle - Refresh Gradle Project, that is. If you do choose to (or must) do Gradle - Refresh Gradle Project anyway, then you need to repeat Steps 2, 3 and 4 again.

I appreciate the above instructions probably look complicated, Graou74. But, I personally don’t think it is complicated in actuality. Written out in text, yeah OK it does look verbose. But it’s pretty simple and straightforward to actually do. Also, you only need to do 1, 2 and 3 just the once.

I emphatically recommend that you watch the most recent recording I uploaded very carefully. Observe carefully, not only everything I do, but also notice what I do not do. I do not do Gradle - Refresh Gradle Project. Because doing so removes all the dependencies from the module path. Which totally counteracts what mrJar is being called on to do.

It would be super helpful too, if you could record a quick screencast showing the precise steps you take that give you the FAILED result. Because I followed the steps that you wrote above. But I got a different result: SUCCESSFUL

I also just made another video. It’s even longer than the one I did yesterday. It’s still rendering at the moment. I’d be happy to upload it when it’s ready. But, it will look familiar to you anyway.

I do not feel any frustration, I test (certainly quickly) for you on Mac. In fact I was sorry for you.

I followed these instructions and I have exactly the same behavior as before. Namely the first launch of “Run As / 1 Gradle test” fails. But after all, everything is fine.

I only watched the last video for only one third. It is way too long and as I said I unfortunately have other priorities.
However I agree to continue testing by following short and precise instructions, in the kind of above.

Sorry. Wrong word choice. I meant I’m sorry mrJar isn’t working the same on Mac as it is on Windows and Linux.

As the developer, any failures cause me to feel some frustration - with software in general, that is. So I assumed you as a user might feel similarly not thrilled with the failures.

Pleased to hear that. Thrilled to be honest :slight_smile:

That gives me the ammunition I need to convince my accountant that I absolutely need to purchase a Mac now :wink:

I can’t thank you often enough for that, Graou74! You rock, man!

TL;DR - To resolve the java.lang.module.FindException: Module java.lang.module.InvalidModuleDescriptorException: not found failure you’re getting @Graou74, edit the build.gradle of that project from this…

 ...
 implementation "org.openjfx:javafx-base:13:$platform"
 implementation "org.openjfx:javafx-graphics:13:$platform"
 implementation "org.openjfx:javafx-controls:13:$platform"
 ...	

to this…

 ...
 implementation "org.openjfx:javafx-base:11:$platform"
 implementation "org.openjfx:javafx-graphics:11:$platform"
 implementation "org.openjfx:javafx-controls:11:$platform"
 ....

The details

I was able to reproduce your java.lang.module.FindException: Module java.lang.module.InvalidModuleDescriptorException: not found failure by changing my $JAVA_HOME from JDK 13 (my Linux box’s default) to JDK 11. Then I repeated the steps you listed:

  1. I just downloaded the project
  2. removed the com.lingocoder plugin from the Gradle cache
  3. imported the project into Eclipse
  4. made a “Refresh Gradle Project”
  5. and then “Run As / 1 Gradle test”

Doing the edit I describe in the TL;DR above made the error go away in my Linux environment.

My apologies for not pointing that out sooner. Up in comment #25 - where I first linked to the MP4 video the other day - I neglected to transcribe any of these points from that video into text…

  • at 1:22 and at 4:00, it shows: Java home directory: /home/lingocoder/.sdkman/candidates/java/13.0.1-zulu
  • at 3:09, the Java Build Path property page shows: JRE System Library [JavaSE-13]
  • at 5:00, the Java Build Path property page shows: java-fx-{...}-13-linux... in the module path drop-down
  • at 15:19, the MyTestApplication run shows: Hello, @Graou74, from JavaFX 13, running Java 13.0.1...
  • at 16:17, the MyTestApplication run shows: Hello, @Lingocoder, from JavaFX 13, running Java 13.0.1...
  • at 18:38-18:48, I double-click on the JavaFX dependencies coordinates in build.gradle to point out that that project is using JavaFX 13

Forgive me for not elaborating on those points in detail the other day. I didn’t because: a) I was too lazy previously :blush: And b) I assumed: A picture is worth a thousand words.

Regarding the optional sub-step of adding --refresh-dependencies to the Buildship wizard’s Program Arguments section that I recommended earlier. If you go that route, be sure that after the initial import has completed, you remove --refresh-dependencies from the arguments. Otherwise, Gradle will redownload all the projects dependencies everytime you execute any task.

To remove that after the initial import…

  1. Go to the project’s property dialog
  2. Go to the Gradle properties tab
  3. Remove --refresh-dependencies from the Program Arguments section
  4. Click Apply and Close

Please let me know if any of that helps? Or not? TIA :+1:

Same behavior with or without --refresh-dependencies. The test is done faster without.

Or there is an altenative which is the virtual machine. I have never tested Mac under PC but the opposite yes and it works very well. In any case, for components as is the case here that do not use very specific drivers it is very satisfactory.
In my case, my PC is down so I naturally turned to the virtual machine to test my application on PC. But no luck, it happens that precisely the main tool on which the application is based is not supported by VirtualBox.:crazy_face:

Bummer.

Incidentally, If you don’t mind me asking: What will your application be used for?

Yup! The Linux you see in my recording is running in VirtualBox actually. That is why everything in that recording looks like it exists in a quantum field made of black strap molasses :blush:

I have had „Install a Mac VirtualBox Guest“ on my TO-DO list for four or five years now. I’ll get around to it any day now, I’m sure :wink:

Right. The idea to remove --refresh-dependencies was only to improve the speed at which tasks complete; not their outcome (SUCCESSFUL or FAILED) as such.

To make sure I understand you correctly — and to avoid making any unneccesary changes to the mrJar code — please confirm that the previously-proposed solution of editing the JavaFX version in the build.gradle from 13 to 11 does not solve the java.lang.module.FindException: Module java.lang.module.InvalidModuleDescriptorException: not found failure on Mac? TIA :+1:

No, it does not change anything. The first “Run As / 1 Gradle test” fails but then the following ones work.
Looks like whatever I do now in the test sequences, whether I forget a phase or not (like not erasing com.lingocoder from the Grade cache), the behavior remains the same.
I wonder if it’s worth it to change the mrJar code. It may be a problem specific to my current environment.

It should be used to model 3D objects and the tool that is not supported by VirtualBox is Vulkan.

I was able to reproduce the InvalidModuleDescriptorException failure on Linux. But only that one time. I tried to reproduce it again so that I could get more insight and try to determine what I need to refactor in the mrJar code. But no matter what I do, I cannot reproduce it a second time :confused:

I have tried several combinations of ways of starting completely from scratch:

  • delete the project’s build folder
  • delete the project’s .gradle folder
  • delete the project’s .settings folder
  • delete the .classpath file
  • delete the .project file
  • add the --refresh-dependencies argument
  • set the Buildship wizard’s Gradle user home field to a brand new, empty location (redownloading/regenerating every single dependency)
  • $JAVA_HOME = JDK 11
  • Eclipse’s JRE System Library = [JavaSE-11]
  • JavaFX version in build.gradle = 13
  • fresh Buildship import

Each time I run your steps…

  1. I just downloaded the project
  2. removed the com.lingocoder plugin from the Gradle cache
  3. imported the project into Eclipse
  4. made a “Refresh Gradle Project”
  5. and then “Run As / 1 Gradle test”

…the :test outcomes are BUILD SUCCESSFUL. They succeed even if Eclipse’s JRE System Library = [JavaSE-11] and the JavaFX version in build.gradle is 13.

The one time I was able to reproduce the InvalidModuleDescriptorException failure, I had a hunch about what code in mrJar might most likely be involved. But even if my hunch was correct, if I can’t reproduce the failure again, there is no way for me to know what in the code to change; I wouldn’t know what specifically to make the refactored code do or what to make it stop doing.

Since you are able to reproduce the failure at will on the Mac, could you — whenever you have a spare five minutes — help narrow down what mrJar code may need refactoring by following these steps? Please?

  1. Edit your settings.gradle to this

    ...
    plugins {
        id "com.gradle.enterprise" version "3.1"
    }
    rootProject.name = 'Graou74'
    
  2. Add this block to the bottom of your build.gradle

    ...
    
    buildScan {
        termsOfServiceUrl = 'https://gradle.com/terms-of-service'
        termsOfServiceAgree = 'yes'
    } 
    
  3. Open Run — Run Configurations — Gradle Test — LibraryTest — Project Settings

    • to the Program Arguments section, add --debug, --stacktrace and --scan
  4. Do whatever steps you do to produce the failure

    • that should dump a ton of output to the console and the stack trace will probably go to Eclipse’s Error log
    • please copy all of that to file(s)?
    • upload them to me?

That would be a tremendous help, @Graou74, if you could. TIA :+1:

Hello again @regrog. I hope you don’t mind me reaching out to you after a month and a half.

But I’m curious to learn your feedback on the solution I proposed for your multiproject question. Please?

If v0.0.15 did the trick for you (or even if it didn’t) mrJar v0.0.16 has been improved majorly since we last spoke. Please, try it out and let me know if it works for you or not?

And if you have any questions, complaints or suggestions for other improvements please get in touch and share your thoughts. TIA :+1:

I do not know if it’s enough as I never registered for Gradle Scan.

console.rtf.zip (12.7 KB)