Question: I'm having some trouble configuring Buildship for Eclipse the way I want. I currently have > 50 projects always open in Eclipse, but I want to move to having only the projects I am actively working on in Eclipse, and the other projects would use a Maven repository to resolve their dependency.

Lets say ProjectA (which contains a main) depends on ProjectB (a library project). If ProjectB is opened in Eclipse, I would like ProjectA to use ProjectB directly. A change in the code in ProjectB would be noticeable when running ProjectA. However, if ProjectB is closed, I would like ProjectA to use the ProjectB's JAR located in the Maven repository mentioned in the build.gradle file.

The behavior that I am talking about is detailed [here](https://issuetracker.springsource.com/browse/STS-2834?focusedCommentId=103757&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-103757).

Is there a way to do that using Buildship? Or should I use another Gradle Eclipse plugin?

Answer: 
1. There's a new [composite build support](https://docs.gradle.org/current/userguide/composite_builds.html) feature added in Gradle 3.1. This feature is a game changer and makes it simple to work on more than one project at once.
2. You can use [dependency substitution rules](https://docs.gradle.org/current/userguide/customizing_dependency_resolution_behavior.html#sec:module_to_project_substitution) to swap out repository dependencies with local project dependencies.
3. If each project is within it's own separate git/subversion repository you can use [prezi pride](https://github.com/prezi/pride) to manage the 'pride' of projects. You could import the (dynamically generated) multi module build into buildship.
4. If you wanted to use the [eclipse plugin](https://docs.gradle.org/current/userguide/eclipse_plugin.html) instead of buildship you use the [whenMerged](https://docs.gradle.org/current/userguide/eclipse_plugin.html#sec:eclipse_modify_domain_objects) or [withXml](https://docs.gradle.org/current/userguide/eclipse_plugin.html#sec:eclipse_modify_xml) hooks to tweak the generated `.classpath` files to point to the projects within your workspace (note eclipse will now build differently to gradle command line).
For the sake of completion, I ended up going with the dependency substitution as suggested by Lance Java. This approach has the following advantages: 

* Does not require a third party software.
* Is IDE independent. We're not tinkering with the `.classpath` file directly, we let the Eclipse plugin (or any other IDE plugin) handle this.
* Other plugins can access the actual dependency we want to use.

However, there are some gotchas with that approach: 

* [Dependency substitution cannot be done inside a task](https://stackoverflow.com/a/32694327/2278844). It needs to be done either in the `build.gradle` file or in a method that is called from the `build.gradle` file.
* You need to refresh the workspace.