Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BEF Major Refactor #32

Closed
plaird opened this issue Dec 9, 2019 · 4 comments
Closed

BEF Major Refactor #32

plaird opened this issue Dec 9, 2019 · 4 comments
Assignees

Comments

@plaird
Copy link
Contributor

plaird commented Dec 9, 2019

We have four major refactoring ideas/goals.

1. Bloated Core Plugin (status: COMPLETED)
The intent of the Core plugin is to be the integration layer to/from Eclipse APIs. The other plugins have no exposure to the Eclipse APIs, which make them reusable (if anyone ever wanted to build a language server) and more easily testable.

But over time, the Core plugin code base has grown and includes too much. The classpath container is a perfect example. About half of that file has nothing to do with Eclipse.

2. Code share with Language Server effort (status: MOSTLY DONE, defer rest to #188)
Another Salesforce team is working on a language server. They are using BEF code and we would like to share work.

bazel-jdt-ls

Other build tooling projects could benefit as well. The isolation work has been completed internally to the BEF repo. The top-level bzl-java-sdk directory is the result of this. Splitting bzl-java-sdk into a new GitHub repo is the intent, but since we are doing heavy development on it in conjunction with BEF I am resisting that move for now. With Git submodules, we could link them, but that just feels like a pain at this stage of development. I am thinking the move out of bzl-java-sdk will occur at the end of the 1.x release line. Issue #188 will track that final step.

3. Non-java projects (defer to Issue #19)
We plan to support other languages than Java in the future. I envision have a set of plugins, like:

  • plugin-java
  • plugin-c
  • plugin-scala
  • plugin-go

that would adapt the Bazel rules for each language into Eclipse projects. I have doubts that this will ever happen beyond Java, and maybe C. See #19

4. Bazel Java SDK (status: COMPLETED)
The idea of the non-Core plugins is to keep most of the code base free of Eclipse dependencies. One of my hopes it to isolate it as a general purpose SDK for anyone who wants to create Bazel build tooling in Java.

@plaird plaird changed the title BEF Core plugin has too much code, refactor down into the underlying libs BEF Major Refactor Mar 31, 2020
@plaird
Copy link
Contributor Author

plaird commented Jun 16, 2020

Bear in mind #131 (find a faster way to compute the dependency graph) which is itself a big refactoring story.

@plaird plaird self-assigned this Jul 1, 2020
@plaird
Copy link
Contributor Author

plaird commented Jul 1, 2020

I accomplished item 4 in the refactor list, culminating in PR #148

@plaird
Copy link
Contributor Author

plaird commented Jul 2, 2020

I accomplished item 1 in the refactor list culminating in this commit which moved the classpath computation from the Eclipse specific plugin to the bazel-java-sdk:
515f818

@plaird
Copy link
Contributor Author

plaird commented Oct 16, 2020

This is done as far to the extent that we need. Follow up Issues noted above track additional work.

@plaird plaird closed this as completed Oct 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant