Hello again! I'm having some trouble with composit...
# community-support
j
Hello again! I'm having some trouble with composite builds. I'm writing a Gradle plugin in a subproject of an existing project, and I'm writing it as an included build. My goal is to use the main project as the dependency substitution for a binary dependency, and also to keep the at-gradle plugin project isolated from the rest of the project. Unfortunately, the dependency substitution I am trying to use doesn't seem to be working. Here's a gist with my relevant files. I figured it'd be a waste of time to try and only send the parts that are relevant, so this gist as the following files:
settings.gradle
,
at-gradle/build.gradle
, and
at-gradle/settings.gradle
. It also includes the log with the failure of task
:at-gradle:assemble
. https://gist.github.com/Jonathing/9c299e883cb83993c25b80b66d81e9e0 The only thing I could think of is maybe it doesn't like that I'm trying to use the root project as an included build instead of a sub project? Thanks in advance to anyone who can give pointers on what's going on. EDIT: Figured it out. Basically it doesn't like if I try to include the rootProject as a build from a subproject that's also an included build. So my compromise was to make an empty root project that includes two builds, where one has the dependency substitution.
v
I didn't look at your code, from what you describe, that's a very bad idea, yeah. One project should never ever ever ever ever ever ever be part of multiple builds.
Ah, or just bad wording
Seems you didn't, but what you did was a circle. Including at gradle build from root build and root build from at gradle build. So probably more a chicken and egg problem, assuming you try to apply the plugin in the root project which you didn't share. Because then you need the root project to build the plugin while you need the plugin to build the root project, ...
Btw. if you
includeBuild
a project with Gradle plugins, you should do so from within
pluginManagement
. And by defining trivial version catalogs in the settings script instead of a TOML file, you give away one of the biggest advantages of version catalogs. If you now change any version, the settings script changes and thus the classpath of every task changes and thus all tasks are out-of-date. If you use a TOML, then only the tasks actually affected will be out of date.
j
Yeah what you described is literally what I did lmfao. When I solved the problem I realized how silly of me that is.
A lot of my older projects (or projects I am taking up working on) use the root project as the source of truth, and I was naively trying to preserve that.
Regarding version catalogs, you bring up a good point. When we started using version catalogs we found it easier (or more realistically, didn't know about the TOML configs at the time) to work with it programmatically in the settings script since it shows us what the types are. On top of that it helps me keep everything related to declaring dependencies in the settings script, since that's also where I declare the repositories.