Recreated test for the issue https://github.com/eclipse/xtext/issues/2920 #1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes the original test of eclipse-xtext#2921 to effectively recreate the original problem of eclipse-xtext#2920
I mean that, without the patched
XtextBuilder
the test fails, with the patchedXtextBuilder
it succeeds.The idea is to create a fictitious additional language extension,
buildertestlanguageGH2920
, and add some extension points in plugin.xml for this language extension, by using a custom executable extension factory and introducing a new customizable activator that, for this "language", redefines the creation ofJdtHelper
to always return false when asked whetherisJavaCoreAvailable
.@stephan-herrmann note that I also slightly modify the way the assertions are performed: in your original test the assertions were made during the build. When they fail, the test ends with an error just saying that the build has failed (this is due to the AssertionError being wrapped in a CoreException being wrapped in a OperationCancelledException). The assertion failure is only printed on the console. This makes it hard to understand it. Now, the possible offending resource descriptions are only collected during the build, and the assertions are made outside the build. This way, when the test fails we get a proper failure message.
@szarnekow I hope this solution makes sense, it took me some time to understand how to inject these customizations only for this test :)