This message was deleted.
# dependency-management
s
This message was deleted.
v
Shouldn't be a problem unless you introduce a real loop
🙏 1
m
Nice! Let's try it 🙂
Following up on this, is there a way to express this cycle in a "centralized way", i.e. without having to remember to do it in both projects as they always require the cycle? Any solution I'm finding so far goes pretty much against the advice in https://docs.gradle.org/current/userguide/cross_project_publications.html and I'm assuming project isolation might make this even more complicated?
j
You could encode it in a (convention) plugin that the projects apply that somehow “knows” which project has which “position” in the cycle. I think it depends on the use case. Hard to give a more concrete answer without knowing that 🙂
m
It's a GraphQL plugin. There's a tradeoff to find between: 1. generating all the possible types 2. keeping the compilation time reasonnable (some schemas are really big and generating everything takes a lot of time) We have a solution that only generates the used types that works well as long as there is a single module. Now if multiple modules are involved, it's not possible to know what types are used without scanning all modules first. The process of scanning is relatively fast so I was thinking of a 2 pass process: • scan all downstream modules for used types • do the actual codegen for these types. The generated code is then used downstream
You could encode it in a (convention) plugin that the projects apply that somehow “knows” which project has which “position” in the cycle
There would have to be some knowledge about the name of the "other" module. It can be really anything. The typical scenario is: • one
schema
module • one
queries
module The
queries
module depends on code generated in
schema
:
Copy code
// queries/build.gradle
dependencies {
  implementation(project(":schema"))
}
The
schema
module depends on used types from queries:
Copy code
// schema/build.gradle
dependencies {
  usedTypes(project(":queries"))
}
But the names can really be anything