I’m not sure if this is a bug or if I’m doing something wrong, but I’m trying to upgrade a project from gradle 4 to 5. I’ve gone through this process successfully with another project, but am having problems with this latest project. Firstly, I’ve run a scan of the build (gradlew help --scan), and the report shows has no deprecations tab). The problem I’m running into has to do with transitive dependencies. I have two branches of the same project (one using gradle 4.10.0 and one using gradle 5.6.4, both making use of the gradle wrapper). In both branches, the build.gradle files are identical and have the following declaration:
which is exactly what I expect and looks correct. However, when I run the same command on the gradle 5 branch, the Google protobuf transitive dependency does not exist in compileClasspath. It does exist in multiple other places including default. All other libraries with transitive dependencies appear to be resolving correctly in compileClasspath. The end result is that I cannot compile on the gradle 5 branch due to unresolved references in my code on protobuf API/classes. I can resolve the problem by adding an explicit dependency on protobuf in my build.gradle, but I would prefer to not have to do that. Can anyone provide any guidance on why this appears to be working differently in gradle 5 and whether I’m doing something wrong?
Earlier versions of Gradle combined all transitive dependencies into the compilation classpath regardless of what was specified in the POM file. As of Gradle 5.0, compile and runtime dependencies are separated. Therefore, runtime dependencies would no longer be included on the compilation classpath.
It’s most likely that com.mycompany.mylibrary:myartifact:1.0 specifies com.google.protobuf:protobuf-java:3.10.0 as a runtime rather than compile dependency in the published POM file. This would automatically be the case if this library is using implementation for the protobuf dependency. Instead, you would want to apply java-library and specify api rather than implementation.
James, Thank you very much for the reply and information. Unfortunately, the library is being built by the Google protobuf plugin. I don’t have any insight into how exactly the plugin is building the jar and the associated pom file that includes the runtime dependency declaration (which I see now thanks to your guidance). I’ll have to go and review the protobuf plugin documentation to see if there are any settings I can alter that control the generated pom file’s dependencies section.
James, I did some more digging, and I believe I understand your recommendation now. I do see that, though the protobuf plugin is creating the jar, the dependencies are specified in our build.gradle file, where I can apply the java-library plugin and specify an api configuration rather than implementation. Hopefully, this fixes the issue. Thanks again for your help!