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.