Altering top level dependencies in subproject

Help/Discuss
1

I have created a settings.gradle that searches an arbitrary directory tree for any Gradle projects and adds them as subprojects:

def searchRoot = rootDir.toPath().resolve(getProperty("searchRoot")).normalize().toAbsolutePath();

Files.walkFileTree(searchRoot, new SimpleFileVisitor<Path>() {
        @Override
        public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) {
           if (file.getFileName().toString().equals("build.gradle")) {
                String projectName = ":" + searchRoot.relativize(file.getParent()).toString().replaceAll("/", ":").replaceAll("\\\\", ":");
                include projectName;
                project(projectName).projectDir = file.getParent().toFile()
            }
            return FileVisitResult.CONTINUE;
        }

        @Override
        public FileVisitResult preVisitDirectory(Path dir, BasicFileAttributes attrs) {
            if (dir.equals(rootDir.toPath()))  {
                return FileVisitResult.SKIP_SUBTREE;
            }
            return FileVisitResult.CONTINUE;
        }
});

This works fine, except that one of the projects that I am importing has two subprojects, one of which has a project dependency on the other, e.g. the build.gradle for subproject A has the following in its dependencies section:

runtimeOnly(project(path: ":project B", configuration: 'confName'))

Because the subprojects have been dynamically included, the project path is now wrong.

So, I am wondering if there is anything I can put in the settings.gradle that will allow me to intercept that dependency and replace the project path with the correct one? I’ve tried putting in a dependencyResolutionManagement section, but that doesn’t appear to be being called.

Thanks,

Carl

2

Why do you not just fix the dependency in A?

3

Unfortunately, that isn’t an option, because the purpose of this script is to allow me to analyse a number of disparate projects without altering them.

However, the more I think about this, the more I think it cannot be done because of the project dependencies

4

Not particularly only because of the project dependencies.

Actually, that is the answer I more or less expected. So now I can tell you: Don’t even think about doing something like that! A given project must never be part of more than one build!

Even if the dependency problem would not be there, you would have various other problems and using it analyzing anything would not make any sense, as you do not run / analyze the actual thing. And also would only work if all those builds use the same (it at least a compatible) Gradle version.

If you really need to combine multiple other builds into an uber build, create a composite build, where you include the builds as a whole into another build. But also this requires that all builds can run with the same Gradle version.