I would like to be a able to get Eclipse to ignore one Gradle project, and instead use a pre-built version of it.

### Background

I have a project "parser" written in Scala, and a dozen others written in Java. The weakest link in my tool-set is Scala IDE. I use this plugin to edit & compile Scala code, but unfortunately it breaks the Java (JDT) tooling quite badly in mixed-language projects\*.

* *Specifically: Call-hierarchy is missing results, searches crash and so on. Also Scala IDE appears to have lost funding and the issues sound fairly fundamental, so I'm not holding my breath for these issues to be fixed.*

With Maven (m2e) I had a workaround I was quite happy with: 

1. Build as a `.jar` put into my local .m2 repository:

```
cd parser; mvn install

```
2. In Eclipse, close the "parser" project

"Like magic", m2e simply picked up the most recent 'installed' .jar and used it in place of the closed project.

*An awesome answer would be how to get Gradle to do that!*

However all I wish for is any solution that meets these...

### Requirements

1. That I can open Project `parser` when necessary (which is seldom),
to edit and build changes via the Gradle command-line.
I will close it when done.
2. Other projects use the built .jar from my local .m2 repo.
(It's fine if they always do so.)
3. The change must not affect others who don't use Eclipse
4. (ideally) the change can be used by other Eclipse users

### Approaches

A similar question had this [good answer](https://stackoverflow.com/a/32609738/932359) by @lance-java with a number of general suggestions. I *think* I can **rule out** these ideas:

* [composite build support](https://docs.gradle.org/current/userguide/composite_builds.html) / multiple repos. Other team members wouldn't think it makes sense to build this project separately, as it is quite closely integrated with the others.
* [dependency substitution rules](https://docs.gradle.org/2.5/release-notes#dependency-substitution-rules) - doesn't appear to meet requirement 3.

Something along the lines of lance-java's idea #4 sounds viable. Paraphrasing...

* "use the [eclipse plugin](https://docs.gradle.org/current/userguide/eclipse_plugin.html) [**in conjunction with**] Buildship, e.g. using the [whenMerged](https://docs.gradle.org/current/userguide/eclipse_plugin.html#sec:eclipse_modify_domain_objects) hook to tweak the generated `.classpath` [**of all the Java projects**]."

UPDATE: [18 Apr]: I had [hit a brick wall](https://discuss.gradle.org/t/a-jar-added-to-the-eclipse-classpath-is-missing-at-runtime/26612) in this approach. Buildship was not putting the built .jar onto the runtime classpath. (UPDATE 2: Now resolved - see my answer.)

Questions
---------

The main question: How can I structure a solution to this, that will actually work & avoid any major pitfalls?

Note that the project itself has a few dependencies, specifically:

```
dependencies {
  compile 'org.scala-lang:scala-library:2.12.4'
  compileOnly  'com.google.code.findbugs:jsr305:1.3.9'
  antlr 'org.antlr:antlr4:4.5.3'
}

```

So a sub-question may be: How to pull these in into the other projects without duplicating the definition? (If that doesn't work automatically.)