Introduce a mechanism to easily register action method signatures

[kaikreuzer]

The Designer of openHAB 1 had most bundles containing actions included and thus way able to resolve these actions in the rule&script editors (for auto-completion, syntax checks etc.).

It also included the possibility to add further bundles in an addons folder by the user, although this mechanism never worked well.

The ESH Designer only contains a few "core ESH" actions. As it is not feasible to automatically bundle action-addons with it, there should be a way to easily add such method signatures (the code itself is not required for the editors).

[SuperOok]

What exactly is the problem that you cannot provide actions later by some bundle? Is it that the Xtext grammar needs to know everything in advance? Isn't this the use case of Xbase integration in the grammar? Or is it an issue with class loading? Maybe fragments or buddy policy help?
Maybe I do not get the problem right.

[kaikreuzer]

The code that provides the action definitions for the scripts/rules can be found here.
As I said, in theory, putting the action bundles in the addons folder should make them being resolved and their services being available.
Feel free to figure out, why this isn't working as expected. A difficult thing to get right is probably that you need all dependencies of the action bundles being available as well - and as the Designer does not have all the bundles of the runtime, this can be hard. That's why I think we would need a new/better mechanism than relying on registered OSGi services here.

[SuperOok]

Hmm... the Designer is an Eclipse RCP Application, so why don't we use Eclipse mechanisms? The Bundles could be explicit Eclipse Plugins and register themselves either via Eclipse extension point or OSGi Service.
For the dependencies a p2 Update Site could be provided such that you can install the addons with the standard Eclipse installation mechanism:
http://www.vogella.com/tutorials/EclipseP2Update/article.html#tutorial_p2ui

Eclipse would then resolve all the necessary dependencies if they are provided by any known update site.

[kaikreuzer]

The Bundles could be explicit Eclipse Plugins

Well, they are explizit OSGi bundles and thus can be installed on RCP, yes.
Using a p2 site merely means that you have the additional overhead of creating p2 feature, a repo and an update site (which you then have to manually add to your Designer first. Also note that the Designer would need all the update site management integrated, so you rather end up with a full Eclipse IDE than just a small RCP application.
And doing all this would not bring you any closer to the solution: You would still have the problem that the action bundles have many dependencies on the runtime, bindings, etc. and you simply won't be able to resolve them all cleanly.

[sjsf]

You would still have the problem that the action bundles have many dependencies on the runtime, bindings, etc. and you simply won't be able to resolve them all cleanly.

This definitely is a pain. The root-cause for all this is the fact that we actually are running more or less a complete runtime framework inside the designer. To my understanding we are doing this mainly to allow the scripts and rules (i.e. Xbase) to use the classpath for looking up what kind of commands should be there. IMHO this completely sucks.

For sure, Xbase by default uses the classpath to resolve its stuff. However, this does not have to stay like that. We could have our own type provider implementation which feeds Xbase with whatever we think should be available (or not...). We don't need access to the real java classes for this, as long as we know how they look like.

Now, assuming we could do the above magic, don't have a full ESH framework running underneath and simply operate on the DSLs: Where do you then know what actions should be available?

One way of solving this would be to introduce a direct connection to the real runtime. I.e. extend it with a REST API to read the available actions (together with all their methods and arguments).

This would "break" the concept that the designer is a real standalone one, because without the connection to the runtime it cannot tell which extensions are there. But let's face it: It is broken today too.

WDYT?

[kaikreuzer]

Yes, having a REST connection was also the intention of #619 and being able to directly read the available actions would be nice.

I only fear that this will mean quite some implementation work, which might not be long-lasting. My hope would be to offer a "designer runtime extension" in the future (see #1402), which would then naturally have access to all details of the runtime (as this is where it is running itself then).

So as a mid-term solution, I think we could do e.g. with an "action.xml" file that the Designer could reference (or e.g. expect to find it in the configuration folder), which could contain information about the solution specific actions (for openHAB, we could maintain such a file that simply has all actions available).

Also note, that with the new rule engine, the "old" actions will be obsolete some day and we might rather allow Xbase to access module types (and we wrap old actions into a module type for backward compatibility).

[htreu]

The designer is not actively maintained anymore, please see #4139 (comment).

@SJKA please close.