Incidentally @Graou74, before you sent your build scan file, I had done some more analysis.
The TL;DR of that analysis only confirmed the usual suspects…
An extraordinarily elusive, practically-impossible-to-reproduce bug in mrJar?
An extraordinarily elusive, practically-impossible-to-reproduce bug in Gradle?
Something peculiar and exclusive to your end only — eg:
your unique Mac environment?
???something else???
That analysis didn’t result in any solutions, I’m afraid. Just questions sans answers. Which hopefully, the requested --debug and --stacktrace output will provide. TIA.
AWESOME! Thank you from the bottom of my heart, @Graou74, for making time to run the test!
Earlier, I said: „That analysis didn’t result in any solutions“. But that’s not the full story. I did follow that hunch I mentioned before, actually. So I did add a single conditional to mrJar to test for that suspcious-looking java.lang.module.InvalidModuleDescriptorException: so-called „module“; the code simply does nothing if that case tests positive.
But that’s not really a solution in my opinion — so much as a band-aid or a work-around to help troubleshoot the real problem.
Because of the multi-threading of the logger, however, I couldn’t conclusively pinpoint precisely which dependency is the problem one. But I’m like ninety-eight percent certain that it is the project’s myApplication.jar. You could help me confirm that with these steps:
Do most of the same steps exactly as you do to reproduce the failure; except…
Do not do the :Run As Gradle Test step; instead…
Do the :assemble task in its place…
either from the command line or from Buildship’s Gradle Tasks view
Upload the resulting build/libs/myApplication.jar to me
The real conclusive solution would be to find out why the problem dependency has an invalid module descriptor in the first place. And to then correct/prevent that. I have another hunch about what that most likely is.
The jar you uploaded does check out with my 11 and 13 runtimes as having a valid module descriptor
However, given all of the other evidence considered as a whole (the debug output, the results of my experiments in Linux, etc) my certainty approaches 100% that your local java.lang.module.InvalidModuleDescriptorException: failure is caused by your local instance of myApplication.jar having been corrupted — somehow.
An InvalidModuleDescriptorException can be caused by several different things. My hunch — based on my recent Googling and experiments — is that one way or another the project’s jar was compiled by javac with a high value for --release (13, say). But then the java runtime that ran the :test task was lower than that value (11, say).
So what do I propose as that real conclusive solution I referred to earlier then? It’s an easy one fortunately: Make sure you check, double and triple check even, that the JDK your project is compiled with is exactly the same as the runtime you expect it to be executed in.
I’m super-duper grateful to you, @Graou74, for you taking the time to help me troubleshoot this. Muy appreciado!
Hello!
I’m really sorry because I can’t keep on trying your plugin these days.
Switching to java 9 modules isn’t so easy because Gradle does not provide a good implementation of it as you can see https://guides.gradle.org/building-java-9-modules/
I remember that your plugin had a clash with Eclipse build folder and that could be a problem using eclipse as IDE.
Because of other dependencies, I can’t update my project and use models, my company can’t do that now. We will schedule this switch as soon as the conditions change.
Thanks a lot for your help, I’ll check your plugin when the times comes.
Thanks for that @Graou74. The more evidence, the better
This is probably one of those cases where we might never know with absolute 100% certainty what the root cause is - because of the intermittent nature of it.
But if the work-around unblocks the correct functioning of the project under test, then I’m thrilled either way.
It is probably fair to put the implementing of a JPMS-architected library or application into the Advanced category.
It’s probably also fair to say that not every project is advanced enough to make JPMS worth the effort.
Or the knowledge/experience of the developer(s) might not be at an advanced enough level to tackle the inevitable advanced challenges that JPMS will certainly present.
So I can totally see what you mean when you say you’re not ready yet. I sincerely appreciate that kind of candid feedback. Thanks
You can see from the lengthy exchange above between @Graou74 and myself, that the mrJar plugin does notclash in any way whatsoever with Eclipse’s build folder.
I point that out, not to persuade you to change your mind, but only to make you aware of a clearly observable fact that you might simply have overlooked.
Thanks again for the feedback, @regrog. And good luck with your project. mrJar will be here for you when you are ready
Hi Lingocoder,
Thank you for this proposal but it will not be necessary.
First because my application is again in its infancy since the transition from OpenGL to Vulkan required a radical change in technology. I took the opportunity to make a global overhaul of the architecture.
Then because I need to do a small part of the development on the OS first because even if Vulkan is cross-platform, it is a bit dependent on the OS.
And finally I got a desktop PC three days ago but the graphics card is integrated and does not support Vulkan.
By cons this PC allowed me to make a boot disk (which I did not manage to do with the Mac) to be able to access again to an old gaming PC that I had loaned and which we could not find anymore the password.
Right now the graphics card is not recognized by Vulkan, I need to check if there is a new driver for this old card.
And if there is none, there are recycled PCs for not too expensive.
Anyway I just became aware even if OpenGL is a bit old (soon no longer supported on Mac), Vulkan is a bit young so I will have to implement both technologies.
I had not planned that.
All three of those projects were excellent functional tests for mrJar v0.0.12, v0.0.13 and v0.0.15. Getting mrJar to work in them meant the plugin had to up its game for each one. Which improved the overall functionality of the plugin amazingly.
That same usage-driven development process also paid off handsomely with this most recent super productive functional testing iteration informed by @Graou74’s 3D modelling application.
I stumbled across mrJar’s latest most advanced functional test case so far in this Stackoverflow question. @Emily describes the problem she’s seeking a solution to, as: „migration of a large code base from Java 8 to modular (JPMS) Java 11“.
mrJarhandled the JPMS migration of such „a large code base“ with such relative ease that even I was surprised at how little time and effort it took!
Not so surprising though is that, just like the other functional test projects, @Emily’s presented some technical requirements that would never have occurred to me if I’d never come across her Li Song Mech Lab project.
So, sincere thanks to all of those projects (@tlinkowski, @siordache, et al) for helping mrJar improve.
