I’m migrating a very large monolithic system with around 1200 gradle projects, each in it’s own git repo.
The dependency map is a big spaghetti ball with circular dependencies which need to be avoided in the CI system so that we don’t trigger endless rebuilding.
In order to avoid that problem I want to keep versioning numbers out of the build.gradle files, so within each project the dependencies are listed something like this:
dependencies {
compile library(group: 'group_A', name: 'name_A', version: ${key})
compile library(group: 'group_A', name: 'name_B', version: ${key})
compile library(group: 'group_B', name: 'name_C', version: ${key})
}
In maven repositories there is a maven-metadata.xml file that contains a set of mappings that almost solves my problem which is essentially to provide some ${key} which resolves to a consistent and tested set of versions from CI. However maven-metadata.xml doesn’t seem to support custom ${key}s which is really my main missing feature because there are lots of developers still used to working in isolated projects who each need to have their own ${key}.
Current we’re building ivy artifacts and storing them in artifactory, but I don’t know if ivy has a similar concept to the maven-metadata.xml (that is supported by gradle). Alternatively I’m looking into using some type of dependency management/resolver that is more gradle-native that might be able to provide equivalent functionality.
Can anyone steer me in the right direction?