Loading a specific resource from a module must use class from module

[arturbosch]

Image following scenario:

A tool (e.g. IntelliJ plugin) uses detekt-tooling to run detekt.
The tool does not include the detekt jars by default (no implementation("detekt-core") usage) but loads them dynamically.
For example the user can specify the detekt version and plugin jars. The tool downloads cli-all.jar and the plugin jars, loads them via a URLClassLoader, gets a DetektProvider.get(): Detekt instance and runs detekt.

Notice that the tool must use the detekt-tooling api which is not inside the URLClassLoader (!). ExtensionSpec was loaded via the AppClassLoader (ClassLoader which wants to load detekt dynamically where detekt-tooling is known). ExtensionSpec.javaClass.getResource won't find the default-detekt-config.yml file.

Conclusion: when loading detekt core and all plugins dynamically detekt's modules are not allowed to use the ClassLoader from detekt-tooling or detekt-api.

[BraisGabin]

To be honest I don't understand how all the resources are loaded. I have little experience in load code dynamically. Is there an easy way to test this to avoid regressions?

[schalkms]

@BraisGabin there were some issues raised in the detekt-intellij-plugin repo that reveal this mentioned problem. For instance:
detekt/detekt-intellij-plugin#190

[BraisGabin]

We can merge this for sure. I'm just wondering if there is a way to unit test it. I assume there isn't.

[arturbosch]

@BraisGabin there were some issues raised in the detekt-intellij-plugin repo that reveal this mentioned problem. For instance: detekt/detekt-intellij-plugin#190

Hm, maybe you linked a wrong issue but this issue seems to be more a detekt-core problem with Intellij 2022.2-EAP. Seems like there will be a breaking change in the Kotlin compiler potentially.

We can merge this for sure. I'm just wondering if there is a way to unit test it. I assume there isn't.

It should be possible to write an integration test for detekt-tooling with a wierd dependency on the detekt-core jar.
Maybe similar how our run cli with args test was done. I'm adding a task to my stack for a future PR :)