requireAllDefinedDependencies gives error when dependency only appears in runtimeClasspath

[unlimitedsola]

First of all, thank you for this awesome plugin!

When invoking requireAllDefinedDependencies on a dependency that has other dependencies that are only available in implementation configuration, it gives a Cannot find dependencies for 'x'. Are 'x' the correct component coordinates? error message.

This issue might be related to how Gradle's application plugin handles the dependency graph differently than normal compilations, as it only fails on :startScripts task, not :classes, but I'm not entirely sure.

From debugging, I notice that code located at here will throw an exception if either compile or runtime classpath is null. But in situations where a dependency "A" wraps another dependency "B" using the implementation configuration, the dependency "B" will only appear on the runtime classpath. Still, I'm not sure why normal compilation (:classes) will pass, I assume in normal compilations both classpath will return empty list instead of null?

I'll provide a reproducible sample project in the comment section.

[unlimitedsola]

Hi, I've created a reproducible sample at https://github.com/unlimitedsola/gradlex-jpms-47 . You can reproduce the issue by executing gradle build task.

The error output is available at: https://github.com/unlimitedsola/gradlex-jpms-47/actions/runs/4791130620/jobs/8521154924#step:4:81

I'm sorry the dependency graph is a bit messy as it was copied from a real project, and I couldn't think of any other libraries that were built from Gradle without module information at the moment.

[jjohannes]

Thank you for trying the feature and reporting. I expected this to not yet work for all cases. The reproducer is very helpful! I will have a look.

[jjohannes]

Thanks again @unlimitedsola your reproducer and analysis made this easy for me to fix.

Your analysis is correct. The compileDependency can be null if it is not known at compile time at all. E.g. it is completely hidden when you compile the module in question. That's why the :classes and :compile... tasks work as they rely on Gradle's compileClasspath only. So they won't even try to find the modules that would trigger the bug. I missed this case in the initial implementation.

The fix will be released in 1.4 shortly.

Unfortunately, I saw that it won't be that simple to turn these Kotlin libs into modules. There are split packages and I think also something unexpected with the service provider definitions. That's what I saw once I tried to run it with the fix.

I think there is nothing wrong in the plugin, but if you should continue on this and find something else, let me know.

[unlimitedsola]

Thanks for your quick fix ❤️! It works perfectly for me now (at least for my particular use case) 😆