eclipse-xtext / eclipse-xtext/xtext
Inline org.eclipse.xtext.common.types.shared.jdt38 fragment?
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 831
- Forks
- 330
- Avg merge
- 3d 7h
- Merged PRs (30d)
- 12
Description
The fragment org.eclipse.xtext.common.types.shared.jdt38 currently contains only two classes of which the OriginalEditorSelector.java can be very useful when e.g. opening test results from the JUnit view for a test case that originates in a Xbase based DSL.
Can you tell why this fragment exists and why it's content is not merged into its host?
I see it has some optional UI dependencies, but so does the host.
Was it created because it uses some, back then new, JDT features?
And would it be reasonable and easily possible to merge into the host nowadays?
For background: I spend some time to find out that this fragment is the 'provider' of the functionality I mentioned above and maybe others could be saved from that too.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by inspecting the org.eclipse.xtext.common.types.shared.jdt38 fragment, its two classes, and the host mentioned in the issue, with particular attention to OriginalEditorSelector.java. Compare their optional UI dependencies and JDT feature usage. Done means documenting why the fragment exists and whether merging it into the host is reasonable.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- tooling
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100