https://gradle.com/ logo
Join Slack
Powered by
trying to create a composite build of all my build...
# community-support
c
trying to create a composite build of all my builds. The individual builds resolve their locks correctly, but when I do 
includeBuild
. The composite projects only job is to execute these like they're one build, not even trying to use them with each other. I had originally thought that since they all have their own dependencies working that I could just 
includeBuild("directory")
but that's not working. Thought maybe I could add a copy of my dependency resolution, but also not working
Copy code
> Could not resolve all dependencies for configuration 'classpath'.
   > Resolved 'com.google.j2objc:j2objc-annotations:3.1' which is not part of the dependency lock state
   > Resolved 'com.google.guava:listenablefuture:9999.0-empty-to-avoid-conflict-with-guava' which is not part of the dependency lock state
   > Resolved 'com.google.guava:failureaccess:1.0.3' which is not part of the dependency lock state
   > Resolved 'org.slf4j:slf4j-api:1.7.36' which is not part of the dependency lock state
   > Resolved 'org.eclipse.jgit:org.eclipse.jgit:7.3.0.202506031305-r' which is not part of the dependency lock state
   > Resolved 'com.google.errorprone:error_prone_annotations:2.41.0' which is not part of the dependency lock state
   > Did not resolve 'com.xenoterracide.gradle.semver:com.xenoterracide.gradle.semver.gradle.plugin:0.12.1' which is part of the dependency lock state
   > Resolved 'com.google.guava:guava:33.5.0-jre' which is not part of the dependency lock state
   > Could not find any matches for com.xenoterracide:tools:0.+ as no versions of com.xenoterracide:tools are available.
     Searched in the following locations:
       - <https://plugins.gradle.org/m2/com/xenoterracide/tools/maven-metadata.xml>
     Required by:
         buildscript of project ':gradle-convention' > project :gradle-semver:semver > project :gradle-semver:git
https://scans.gradle.com/s/glkk5pgic2mdw
Untitled.kt
Untitled.kt
v
Never used dependency locking, but maybe it is a bug? I neither see composite builds in the known limitations of the locking docs, nor an open issue regarding it.
At least it might be a documentation bug if that is intended behavior
c
I highly doubt it... seems to me the problem is it's trying to find 
tools
and not picking it up... I could try disabling the locks... but I'd bet money that just gives a different error
but then gradle is full of strange issues due to them not finishing features
yeah, some of the builds work with lockfiles just fine, I would say it's not that
it looks like it's just this one build... suspicious
v
Ah, didn't read that far. Just have seen the first couple where it said "resolved X which is not part of the dependency lock state"
c
no wait, I lied, it's all but! one build...
which is still strange
my 
includeBuild("gradle-semver")
works, but all of the rest are causing this failure 😕
the only thing I've found broken with lockfiles is that bots don't know how to update them correctly
any auto-updates have to be managed by us because the bots don't work correctly (with gradle pretty much period tbh)
unfortunately I'm going to have to return to this later, feel free to take a look at the submodule project though, perhaps something pops. Currently the other subprojects are not included, and the version-catalog is probably just broken so I haven't tried to do 
includeBuild
on it. In order to make things work you have to setup a github pat per documentation in say the spring-app-commons (or any of the submodules)
Copy code
❯ cat ~/.gradle/gradle.properties
ghUsername = xenoterracide
ghPassword = ghp_...
https://github.com/xenoterracide/Projects
this makes no sense to me... but it would appear that my fix is to put git submodule projects that are composite gradle plugins into the pluginDependencyManagement as 
includeBuild
Copy code
pluginManagement {
  repositories {
    gradlePluginPortal()
  }
  includeBuild("gradle-semver")
  includeBuild("gradle-convention")
}
I find it strange because I'm not trying to do an apply here... all I'm doing is including the builds. Junie figured this out O.o I hate it 😕
Copy code
You attached multiple independent builds via a composite (includeBuild). As soon as one of those builds (here, gradle-convention) applies the gradle-semver plugin, Gradle tries to resolve that plugin from the plugin repositories. Because the semver plugin internally depends on your java-commons library (com.xenoterracide:tools), that dependency also needs to be resolvable during plugin/classpath resolution.
this is even more fun because that dependency gets baked into the output, and so that makes me wonder 2 things... one if this plugin works for not me... and 2 if the metadata is wrong since tools is supposed to be shadowed in the jar.
5 Views
Open in Slack
PreviousNext
Powered by