In a complex project with included builds, Java subprojects, and native C++ subprojects, a specific Java JAR dependency fails to be found in the expected Maven repository. If I comment out all native C++ subprojects, though, the Java JAR dependency is found correctly.
Expected Behavior
When looking for Java dependencies in Maven repositories, Gradle would typically try to fetch various files: .pom, .module, .jar, etc. In my particular case, there is no .pom file and no .module file, but a .jar file is present. I have not specified a version number, so Gradle should first fetch the appropriate maven-metadata.xml file to determine what versions are available. It should then fetch a suitable .jar file for the latest available version, and use that to satisfy the dependency.
This should all happen consistently for projects that use the java or application plugins. If some submodules in the included build use cpp-library or cpp-application, this should have no effect on how Gradle uses Maven repositories to find dependencies for Java build targets.
Current Behavior
If I comment out the two cpp-library subprojects and the one cpp-application subproject in the included build, then all works as described above to find Java dependencies on JAR files located in my Maven repository.
If I re-enable the two cpp-library subprojects and the one cpp-application subproject in the included build, then the Gradle assemble task for my top-level Java application project fails with the following diagnostic output:
FAILURE: Build failed with an exception.
* What went wrong:
Could not determine the dependencies of task ':shadowJar'.
> Could not resolve all dependencies for configuration ':runtimeClasspath'.
> Could not find any matches for eclipse-deps:org.eclipse.core.runtime:+ as no versions of eclipse-deps:org.eclipse.core.runtime are available.
Searched in the following locations:
- https://jcenter.bintray.com/eclipse-deps/org.eclipse.core.runtime/maven-metadata.xml
- file:/home/liblit/Documents/research/joust/joust/WALA/build/p2asmaven/maven/eclipse-deps/org.eclipse.core.runtime/maven-metadata.xml
- file:/home/liblit/Documents/research/joust/joust/WALA/build/p2asmaven/maven/eclipse-deps/org.eclipse.core.runtime/3.13.0.v20170207-1030/org.eclipse.core.runtime-3.13.0.v20170207-1030.module
- file:/home/liblit/Documents/research/joust/joust/WALA/build/p2asmaven/maven/eclipse-deps/org.eclipse.core.runtime/3.13.0.v20170207-1030/org.eclipse.core.runtime-3.13.0.v20170207-1030.pom
Required by:
project : > project :com.ibm.wala:com.ibm.wala.cast.js.test > project :com.ibm.wala:com.ibm.wala.core.tests
Look carefully at the Searched in the following locations list. The second item listed, file:/home/liblit/Documents/research/joust/joust/WALA/build/p2asmaven/maven/eclipse-deps/org.eclipse.core.runtime/maven-metadata.xml, does actually exist and lists one known version of the org.eclipse.core.runtime artifact: 3.13.0.v20170207-1030.
Now look at the third and fourth items in the Searched in the following locations list. Observe that Gradle is looking for the promised version of the dependency as either a .module file or a .pom file. Neither of those exists. What does exist is a .jar file, but for some reason Gradle never attempts to find that. A low-level system-call trace confirms that Gradle never attempts to access the .jar file which would actually satisfy the dependency. It is as though .jar has somehow been removed from the list of possible ways to satisfy this dependency.
Context
Although this all seems very Java-specific, I claim that the native plugins are involved somehow. The entire build worked just fine back when the native components were built using the Gradle software model. This failure only arose after I ported the native components to build using cpp-library and cpp-application instead of the software model.
Additionally, if I modify the included build’s settings.gradle to comment out the two cpp-library submodules and the one cpp-application submodule, then the rest of the build works just fine. Only when I start loading the native plugins does Java dependency resolution forget to look for .jar files.
Steps to Reproduce (for bugs)
I regret that I cannot provide a complete-but-simple sample project to reproduce the problem. Unfortunately the project in question is just not ready for public release. I can say that the included subproject is a tweaked variant of the T.J. Watson Libraries for Analysis, whose native components are built with logic found here, here, and here. I cannot make our tweaks available either. From a build-logic standpoint, the most significant tweaks are that some of WALA’s test Java sources have been recategorized as main Java sources in our tweaked variant.
Our tweaked copy of WALA builds fine either with or without the cpp-{application,library} subprojects. This problem does not affect WALA directly. Rather, the problem arises when WALA is used as an included build within a larger composite build (that I unfortunately cannot yet release). When building that larger project, if the cpp-{application,library} WALA subprojects are not commented out, then Java dependency resolution fails as described above.
Again, sorry for being unable to provide more detail or a complete working demonstration of the problem.
Your Environment
I am using Gradle 5.2.1 on a Fedora 29 (Linux) system with a gcc-based toolchain for native builds.
In a complex project with included builds, Java subprojects, and native C++ subprojects, a specific Java JAR dependency fails to be found in the expected Maven repository. If I comment out all native C++ subprojects, though, the Java JAR dependency is found correctly.
Expected Behavior
When looking for Java dependencies in Maven repositories, Gradle would typically try to fetch various files:
.pom,.module,.jar, etc. In my particular case, there is no.pomfile and no.modulefile, but a.jarfile is present. I have not specified a version number, so Gradle should first fetch the appropriatemaven-metadata.xmlfile to determine what versions are available. It should then fetch a suitable.jarfile for the latest available version, and use that to satisfy the dependency.This should all happen consistently for projects that use the
javaorapplicationplugins. If some submodules in the included build usecpp-libraryorcpp-application, this should have no effect on how Gradle uses Maven repositories to find dependencies for Java build targets.Current Behavior
If I comment out the two
cpp-librarysubprojects and the onecpp-applicationsubproject in the included build, then all works as described above to find Java dependencies on JAR files located in my Maven repository.If I re-enable the two
cpp-librarysubprojects and the onecpp-applicationsubproject in the included build, then the Gradleassembletask for my top-level Java application project fails with the following diagnostic output:Look carefully at the
Searched in the following locationslist. The second item listed,file:/home/liblit/Documents/research/joust/joust/WALA/build/p2asmaven/maven/eclipse-deps/org.eclipse.core.runtime/maven-metadata.xml, does actually exist and lists one known version of theorg.eclipse.core.runtimeartifact:3.13.0.v20170207-1030.Now look at the third and fourth items in the
Searched in the following locationslist. Observe that Gradle is looking for the promised version of the dependency as either a.modulefile or a.pomfile. Neither of those exists. What does exist is a.jarfile, but for some reason Gradle never attempts to find that. A low-level system-call trace confirms that Gradle never attempts to access the.jarfile which would actually satisfy the dependency. It is as though.jarhas somehow been removed from the list of possible ways to satisfy this dependency.Context
Although this all seems very Java-specific, I claim that the native plugins are involved somehow. The entire build worked just fine back when the native components were built using the Gradle software model. This failure only arose after I ported the native components to build using
cpp-libraryandcpp-applicationinstead of the software model.Additionally, if I modify the included build’s
settings.gradleto comment out the twocpp-librarysubmodules and the onecpp-applicationsubmodule, then the rest of the build works just fine. Only when I start loading the native plugins does Java dependency resolution forget to look for.jarfiles.Steps to Reproduce (for bugs)
I regret that I cannot provide a complete-but-simple sample project to reproduce the problem. Unfortunately the project in question is just not ready for public release. I can say that the included subproject is a tweaked variant of the T.J. Watson Libraries for Analysis, whose native components are built with logic found here, here, and here. I cannot make our tweaks available either. From a build-logic standpoint, the most significant tweaks are that some of WALA’s
testJava sources have been recategorized asmainJava sources in our tweaked variant.Our tweaked copy of WALA builds fine either with or without the
cpp-{application,library}subprojects. This problem does not affect WALA directly. Rather, the problem arises when WALA is used as an included build within a larger composite build (that I unfortunately cannot yet release). When building that larger project, if thecpp-{application,library}WALA subprojects are not commented out, then Java dependency resolution fails as described above.Again, sorry for being unable to provide more detail or a complete working demonstration of the problem.
Your Environment
I am using Gradle 5.2.1 on a Fedora 29 (Linux) system with a
gcc-based toolchain for native builds.