Tests failing

[datho7561]

Some tests are failing, preventing a snapshot from being released

[rgrunber]

This has improved a little with #479, #480, #481 but I think there's still a few testcases that fail intermittently.

I think the big issue is that some of the "feature registration" is not properly set up as the tests being to run, and this causes those contribution to be skipped, which is why you get things like "expected .... but was 0/[]/empty". Other than that there's 1 testcase that relies on javadoc which might need a proper update.

[datho7561]

Other than that there's 1 testcase that relies on javadoc which might need a proper update

namely: MicroProfileFaultTolerancePropertiesTest.microprofileFaultTolerancePropertiesTest "Test 'description' for 'Bulkhead/value'"

Note that this failure is not intermittent, and is in fact legitimate; the link doesn't appear in the hover docs.

update this is intentional; the link is resolved as a separate step in order to speed up the extension. It doesn't appear to work yet in vscode-microprofile because the corresponding change we need for it to work properly hasn't been merged yet: redhat-developer/vscode-microprofile#246

update actually, this is a problem with how we are testing it, and I know how to fix it. Notice this line:

lsp4mp/microprofile.jdt/org.eclipse.lsp4mp.jdt.test/src/main/java/org/eclipse/lsp4mp/jdt/core/BasePropertiesManagerTest.java

Line 171 in 42885a2

JavaLanguageServerPlugin.getPreferencesManager().updateClientPrefences(new ClientCapabilities(), new HashMap<>());

. We are disabling the link support on the JDT side by clearing the extended client capabilities hash map! Maybe this is desirable, since it means that the docs string be the same on every computer it runs (the link usually contains the absolute path to the jar, so we have it hardcoded to the path Jenkins uses)