JSON deserialization issues with included build plugins

Hello,

I’m facing a very odd issue in my gradle multi-module project. It is set up like this:

(root)
  - build-logic (included build)
    - convention plugin
    - other plugin using the testcontainers library, containing a task that starts a container
  - submodule

I am applying both plugins in submodule. The convention plugin is applied in the root project.

When I run the task to start the container, I am seeing a NPE when handling the deserialized response from the docker engine. After some debugging, I found out that the root cause of the NPE seems to be that the @JsonProperty annotation is not respected, leaving the response object with mostly null values.

However when I remove the convention plugin from the root project, the issue is fixed and the container starts properly. The issue is also fixed when I remove the dependency to the Micronaut Gradle plugin from the convention plugin.

I’m relatively inexperienced when it comes to multi-module gradle projects. I could understand if both plugins in one submodule interfere with each other, but having the plugin in the root project interfere with the build of a submodule is surprising to me.

I’d appreciate if anyone could me point into the right direction as to what might go wrong here.

Thanks,
Tobias

The class loaders for the build scripts form a hierarchy.
The class loader for the root project is the parent class loader of the class loader for submodule.
So by only having both plugins in submodule, there is conflict resolution for common dependencies and so on and the classes are all in the same class loader.
By having the convention plugin in the root project, it and all its dependencies are taken from that class loader.
This can lead to problems for example if otherwise there would have been conflict resolution, or if something from the root project class loader needs to access classes from the submodule class loader.

You can most probably mitigate the problem by adding the “other plugin” also to the root project but with “apply false”. This way it also lands in the root project class loader and it will probably behave as expected from what you described.

Thank you for the quick response. This makes sense to me and your proposed mitigation has also worked.

1 Like