Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [smarthome-dev] The future of the ESH Designer

Hi,

> So my proposal would be to move towards providing LSP support for the
> DSLs in ESH. It would need an Xtext upgrade [4] and some
> yet-to-be-done voodoo to actually generate the LSP stuff with Xtext in
> our build and integrate them into our runtime.

sounds like a plan. ;)
Is your branch for the Xtext bump ready to use?
It would be happy if we could drop of the redistributed or patched
bundles currently used for Karaf:

* mvn:de.maggu2810.thirdparty.modified.org.eclipse.xtext/org.eclipse.xtext.xbase/2.9.2.sp1
* mvn:de.maggu2810.p2redist/com.google.inject/3.0.0.v201312141243
* mvn:de.maggu2810.p2redist/com.google.guava/10.0.1.v201203051515
* mvn:de.maggu2810.p2redist/org.antlr.runtime/3.2.0.v201101311130
* mvn:de.maggu2810.requirebundle.fix/org.objectweb.asm/5.0.2

> With that, we could limit the "official" DSL editing support to this,
> i.e. drop the current Designer and NOT provide our own standalone one
> anymore.
>
> There already is a VSCode implementation for openHAB [5] that would
> just need to be connected to the LSP backend [6] on order to really
> understand the grammar, which could be the first example. But of
> course there might be others driven by the community or by some
> commercial solutions.

I am not using the Designer myself (the DSL at all) but as there is
currently an Eclipse SmartHome Designer available there should still
be a solution available in future.
If we could point people to the openHAB implementation it is IMHO an
acceptable solution as long as that implementation does work with
plain ESH, too.

Best regards,
Markus


Back to the top