Disable adding other projects as dependencies

Help/Discuss
1

I am working on a custom gradle plugin which consolidates all of the standard gradle config that my company normally copy and pastes around to every repo. This plugin is written against Gradle 7.1.1

We want to add an additional feature to this plugin, and this is to fail if any developer specifies another project as their dependency.

eg:

dependencies {
    implementation project ('myParentProject:myChildProjectName')
}

We have had numerous issues over the years due to this, and we believe that developers should only depend on pre-compiled artifacts instead of project source code directly. So in that example I would expect to see this instead:

dependencies {
    implementation 'myCompaniesGroup:myChildProjectName:0.1'
}

Is there any way to programmatically enforce this? I have been poking around the source code of DefaultDependencyHandler and I would like to be able to overwrite the implementation of

public Dependency project(Map<String, ?> notation) {
    return this.dependencyFactory.createProjectDependencyFromMap(this.projectFinder, notation);
}

To throw an unsupported operation exception. Or maybe theres a way for me to iterate all of the dependencies in a project.afterEvaluate(), try to cast them to ProjectDependency.class, and if they are able to be casted then throw an exception.

2

After evaluation, you can iterate over each configuration to get their dependencies and check for project dependencies. In case there is one declared → throw an exception.

3

I’m interested in hearing about what issues you have encountered.

4

Hey Chris,

A lot of the issues we have stem from poor repository structure and layout. We have massive multi-project repos, with 500-1000 projects in some cases and there are situations where we have

project A – has some code we want to reuse
project B,C,D,E,F,G, etc – all depend directly against the projects source code.

Making changes to project A is now extremely risky and if I making non-backwards compatible changes and updating APIs, a simple change will balloon in scope as we have to change project A and all of it’s usages in a single PR due to compilation failures.

We are trying to decompose our repositories to reduce these issues, and this standardized plugin is an important piece of that idea, but the thought is that if project B,C,D,E,F,G, etc all depend against artifacts from a maven repository, we then de-couple the changing of the API and the usage of the API and changing project A is much less risky. Project B,C,D,E,F,G may never even need the new code/functionality.

I am afraid that even if we decompose our massive repos now into much smaller ones, it’s possible to get back into the same position over time and we just want to programmatically enforce people from not depending directly on a project directly.