Eclipse inter-project dependencies missing

Help/Discuss Buildship
,
3

I believe I found a near-root cause, if not the root cause of this last night.
I described much of this in a related post (see edit #5): The project was not built due to "Resource already exists on disk" errors in eclipse

Digest of what is relevant to this thread:

A bit of a background as there are two issues working somewhat together here:

  1. Gradle offers us fine grain control over “dependency configurations” (and dependencies). These can depend on artifacts, local file system, other projects and (other) project configurations (and do some more). Some come out-of-box but we can create our own.
  2. One of the out-of-box configurations is (called) “default”. In Java world it brings together what the project’s code needs with that code itself, packaged in a jar.
  3. Normally, when one project’s code expresses a “project” dependency it isn’t actually a project dependency at all but a dependency on that project’s default configuration. Difference is small but significant and important. If you think about it, if one project depends on another it means multiple similar but distinct things not captured by simplified dependency on project’s default configuration. Imagine project A depending on project B. At high level this usually means the following:
    • A’s implementation depends on B’s code (without transitive dependencies in the strictest sense)
    • A’s runtime (runtimeClasspath) additionally depends on B’s transitive implementation dependencies + all runtime dependencies (transitively as well)
    • A’s testImplementation possibly depends on B’s test code (without transitive dependencies in the strictest sense)
    • A’s test runtime (testRuntimeClasspath) possibly additionally depends on B’s transitive test implementation dependencies + all test runtime dependencies (transitively as well)
  4. Depending on default requires/depends on building jars which takes some time and space that isn’t always needed - say to run unit tests, as these can be run directly from unpackaged output directories.

Now:

  • To get clean dependencies as in (3) and avoid dependency pollution that would stem from either explicit or implied dependencies on default configurations and to squeeze a little bit more build performance (4), we do not use default configurations at all. We explicitly use clean configurations and define some of our own (to include actual output directories as opposed to jars, for example).

The issue:

Inter-project dependencies end up missing in Eclipse (see Eclipse inter-project dependencies missing) probably because Buildship only looks at dependencies on default configuration that we specifically omit.

Resolutions?

In the short term we will try to recognize/detect Buildship in/from our Gradle scripts and declare “default” default configuration dependencies. We’ve confirmed that this addresses the inter-project dependencies issue. We are hoping that there is a way to detect Buildship indirectly, such as by setting some system property for Eclipse (as we don’t know of a direct way). Will report.

In the long term:

  • Gradle should evolve beyond the insufficient way of declaring project dependencies to simply be dependencies on default configuration.
  • Buildship should also consider non-default configuration dependencies when determining Eclipse inter-project dependencies.