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.
The --debug output has confirmed what I suspected from analysis: the root cause of that java.lang.module.InvalidModuleDescriptorException: is that one of your dependencies has a module descriptor that: „is found to be malformed or otherwise cannot be interpreted as a module descriptor“.
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 Teststep; instead… - Do the
:assembletask in its place…- either from the command line or from Buildship’s
Gradle Tasksview
- either from the command line or from Buildship’s
- Upload the resulting
build/libs/myApplication.jarto 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.