ideaModule tries to remotely resolve javadoc and source of inter-project dependencies


(Jörn Huxhorn) #1

All of a sudden, we get the following error message.

FAILURE: Build failed with an exception.
  * What went wrong:
Execution failed for task ':foobar:foo.bar:ideaModule'.
> Could not resolve all dependencies for configuration 'detachedConfiguration2'.
   > Module version group:foo, module:foo.bar, version:1.0.0-SNAPSHOT, configuration:detachedConfiguration2 declares a dependency on configuration 'archives' which is not declared in the module descriptor for group:xxx, module:xxx.yyy, version:1.2.0-SNAPSHOT

xxx:xxx.yyy is an internal dependency in the same multi-module project. ideaModule tries to resolve javadoc and source jars from our nexus repository where no such artifacts are currently present due to the previously reported issue.

So while this is a side effect of another problem, it is quite strange anyway. Why are the artifacts resolved from the remote repository instead of simply created?


(Jörn Huxhorn) #2

Alright, we found the reason for this - as well as a workaround.

This was caused by a dependency problem.

We have two git repositories, X & Y, with separate builds. X is older stuff that is still using Maven while Y is already using Gradle.

X:foo has a dependency on Y:bar which in turn depends on X:foobar, all of them SNAPSHOTs.

Not nice but not immediately changeable. Legacy, historical reasons etc…

Our current solution is to explicitly exclude the X:foobar dependency of the Y:bar dependency in X:foo, manually adding X:foobar as a gradle-internal project dependency to X:foo instead.

Is there an easier way to “re-attach” transitive dependencies that are part of the current multi-project?


(Luke Daley) #3

This is GRADLE-2709.

There’s no built in detection or handling of this kind of situation at this time. The best approach is the exclude as you have done.


(Jörn Huxhorn) #4

Ah, I see. And GRADLE-2713.

Thanks for the fast response.