Howto change transitive dependency into project dependency

(Oliver Wahlen) #1

I am working in an environment with several dependent gradle projects each of which result in artifacts in a Maven repo.

If developers want to test code changes in a sub-project they have to create snapshot releases, deploy them locally and then compile the parent project. This is very tedious and also does not allow to do cross-project code refactorings in the IDE.

My idea is to make the top-level project configurable: Dependencies can either be resolved from artifactory or be gradle sub-projects (i.e. a gradle multi-project environment). I already managed to make the relevant changes to settings.gradle and also configure the direct dependencies.

Unfortunately I am currently unable to transform the transitive Maven dependencies into project dependencies.

In other words I am trying to do something like this:

allprojects { Project subproject ->
    subproject.configurations.all { Configuration configuration ->
        configuration.resolutionStrategy { ResolutionStrategy strategy ->
            strategy.eachDependency { DependencyResolveDetails details ->
                if (details.requested.name == 'myartifact') {
                    details.useTarget project(':myproject')
                }
            }
        }
    }
}

The relevant line is the one with useTarget. This method allows to override a module dependency with another module (from a maven repo) Unfortunately this method does not accept a project dependency. So the code above expresses my intent but it does not work like this.

Any ideas?

(Jason Hatton) #2

How will our the project source get to the workspace? Will the developer check it out as a subproject?

I guess you would do directory exist checks and switch which dependecy to use based on the whether the subproject directory exists. Would this achieve what you want?

#3

You might want to look at https://github.com/pniederw/elastic-deps for a solution.

(Oliver Wahlen) #4

The mechanims we have in place are quite similar to elastic-deps. However I think elastic-deps has the same problem that we have:

Let us assume project sub1 and sub3 are located on the local drive. I.e. they shall participate in a multi-project build. The project sub2 is located in a maven repo.

If we now build elastic-deps it will compile sub1 and sub3 nicely from our local drive.

But when composing the final build artifact it will also fetch sub3 from the maven repository. It does this because the pom.xml of sub2 that is located in the maven repo will point out a dependency on sub3. The gradle resolver does not understand that it is not supposed to fetch sub3 transitively from the maven repository.

As a consequence when you run gradle eclipse you will also have two jars in the .classpath that contain code from sub3. Even worse the compiled classes may even differ resulting in classloader issues.

Transitive Dependencies are not resolved to project dependencies