Upgrade to Xtext 2.19, LSP4J 0.8.0 and fix LSP server

[wborn]

Every connection to the LSP server failed because it always threw a org.eclipse.smarthome.model.ide.SitemapIdeSetup NoClassDefFoundError.
Which is caused by the SitemapIdeSetup residing in a package that is split between both the org.openhab.core.model.item.ide and the org.openhab.core.model.sitemap.ide bundles.
The SitemapIdeSetup class is also using classes from the org.eclipse.smarthome.model package which is also a package split between the org.openhab.core.model.items and org.openhab.core.model.sitemap bundles.
After renaming the packages used for the sitemap classes the NoClassDefFoundError is resolved and LSP works properly again.
Many imports were updated for the sitemap model package changes.

Fixes #1030

---

For the Xtext update we need to deploy io.github.classgraph_4.8.35.v20190528-1517.jar from Eclipse Orbit (see recipe) to our own repo because feature validation fails with the version available from Maven Central.

If this is the way to go I can also make some PRs with the changes for the other repos:

openhab2-addons: wborn/openhab-addons@72fc184
openhab-webui: wborn/openhab-webui@15e76b1

I've renamed the sitemap model packages similarly to how they are also used with the thing and script models. As you can see in the webui changes it does result in sitemap.sitemap being used in the imports which does seem a bit odd.

My local build with these changes is available in this release:

https://github.com/wborn/openhab-core/releases/tag/update-xtext-lsp4j-fix-ncdfe-release-tag

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/brace-yourselfs-theres-activity-again/83998/4

[kaikreuzer]

Wow, great work, thanks!

For the Xtext update we need to deploy io.github.classgraph_4.8.35.v20190528-1517.jar from Eclipse Orbit to our own repo

@J-N-K You're the master of our dependency management: Shall this be added to https://bintray.com/openhab/mvn/openhab-addons-deps (despite the fact that it isn't an add-on dependency, but a core dependency)? Or do you have any better place?

[wborn]

We might also want to use this repo for the artifacts currently obtained from @maggu2810's private repo (#960).

[J-N-K]

I think that creating an additional repo for a single dependency is a bit overkill. Can we rename the repo to openhab-dep? Would be a better fit.

[kaikreuzer]

I would just leave the name as is and don't worry too much about it.
@J-N-K Could you take care of uploading the new lib there?

[J-N-K]

Done. Please try if it works as expected.

[wborn]

Many thanks @J-N-K! I think it works after updating the GAV and adding an exclude of the original artifact.

[kaikreuzer]

Let's get that merged, so that we have a few days to test the effects before the next milestone :-)

[maggu2810]

Just to track it somewhere:

With this change openHAB relies on "Log Service Specification" version 1.4.

[wborn]

Do you think that is a positive change or might it cause problems?

[maggu2810]

It might cause problems.

The "Equinox Common" tries to access the Equinox Logger (see package "org.eclipse.equinox.log") that one is provided by "Equinox Supplement". Additionally if you use the Equinox framework it is also provided by that one.

The Equinox Logger implements the Logger interface of the OSGi Log
Service specification 1.4
https://github.com/eclipse/rt.equinox.framework/blob/63a9e1075ab029c5090a3d50cf52b82f052c62f6/bundles/org.eclipse.osgi/supplement/src/org/eclipse/equinox/log/Logger.java#L23

The "Equinox Supplement" does not usage version constraints at all on
its imports:
https://github.com/eclipse/rt.equinox.framework/blob/63a9e1075ab029c5090a3d50cf52b82f052c62f6/bundles/org.eclipse.osgi/supplement/META-INF/MANIFEST.MF#L25

Pax Logging provides the OSGi Log Service specification 1.3.

So, as soon as "Equinox Common" is using "Equinox Supplement" that requires "org.osgi.service.log" (without a version constraint) and it is bound to Pax Logging that provides 1.3 and it accesses the Logger interface that class is only available on 1.4 you will get a CNFE.

If you are using the Equinox Framework (which you did for the openHAB Distribution) it works because this one bundles the desired stuff.

If you use Apache Felix and so no other bundle that provides an 1.4 log implementation. Boom 😉

In general I assume a core framework should not provide a service implementation of the compendium itself, but that's just my feeling.

[wborn]

I think you're right about that and I only did some integration testing with Equinox at the time. It might be good to track such incompatibilities in issues so they are also more easily discovered by others that use OHC without Equinox.

[maggu2810]

Just FYI:
For the ones like me that want to use the Felix framework in the current Karaf versions and the recent code base, this org.eclipse.equinox.supplement should work.