Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Isolate the Rules DSL and package it as a bundle #526

Closed
5iver opened this issue Feb 4, 2019 · 7 comments
Closed

RFC: Isolate the Rules DSL and package it as a bundle #526

5iver opened this issue Feb 4, 2019 · 7 comments

Comments

@5iver
Copy link

5iver commented Feb 4, 2019

As we transition to the NGRE, we will need the ability to choose which engine is installed on a system. I will begin researching this, but wanted to quickly throw this out here to pull in others that would like to help and/or discuss.

@kaikreuzer
Copy link
Member

This should be really fairly simple - we already have dedicated Karaf features for the DSL rules, so those could be simply made optional, once we do not want to package the "old" rule engine by default anymore.

@5iver
Copy link
Author

5iver commented Feb 4, 2019

That info probably saved me a couple hours! Is there a way to turn a Karaf feature into a bundle, so that someone could choose to install/uninstall through Paper UI?

@kaikreuzer
Copy link
Member

kaikreuzer commented Feb 5, 2019

Sounds as if you still have to learn a bit about Karaf features 😎 - they cannot be "turned into a bundle", they are simply a set of bundles (roughly speaking).
And they are the entities that you can install+deinstall in Karaf/openHAB.

Features with a specific naming (openhab-<addontype>-name, e..g. openhab-misc-ruleengine) are automatically shown in the Paper UI.

@5iver
Copy link
Author

5iver commented Feb 5, 2019

Sounds as if you still have to learn a bit about Karaf features sunglasses -

Yes... this is definitely an area I'm not familiar with! 🙂 I'd like to make this change locally to test (and learn!), but I'm not sure I understand the mechanism for toggling optional/required.

I see an /etc/org.apache.karaf.features.cfg with featuresBoot in my local install, but I can't find this file in the repo. I'm also not sure which line in featureBoot installs openhab-core-model-rule. But if it is removed from features.xml, this should prevent it from installing by default.

Then, move org.openhab.core.model.rule into openhab2-addons? Although, it seems strange to currently have it in openhab2-core, so why not move it now, after the smoke settles from the ESH migration?

A rule engine is at the heart of an HA system, but shouldn't it be optional, for people who DIY their own (e.g. node-RED)? I'm not saying to make it an optional feature now, but maybe in OH3 make them both optional?

@Misiu
Copy link

Misiu commented Mar 28, 2019

@openhab-5iver I'm relatively new to openHAB but I like the direction it is taking.
I really like Node-RED and I support Your idea.
The idea to have an option to install/uninstall default rule engine and install Node-RED as a replacement would be awesome 🚀
@kaikreuzer maybe this could be considered for OH3?
There also should be tighter integration with non-default rule engines, for example if user will install Node-RED he should see Node-RED instead of Rules here:
image

@5iver
Copy link
Author

5iver commented Jan 3, 2020

@kaikreuzer,

  1. Should the old rule engine be removed completely in OH 3.0 or just made to be optional?
  2. As stated above, IMO the new rule engine should stay optional. WDYT?

I'd be happy to submit the PRs for these!

@kaikreuzer
Copy link
Member

Should the old rule engine be removed completely in OH 3.0 or just made to be optional?

Depends on whether we can make existing rules work on the new rule engine with merely small adaptations. As long as we don't have an answer to this, it should be optionally available.

As stated above, IMO the new rule engine should stay optional. WDYT?

It should be technically an independent component, but any standard openHAB setup must have it included. Just like @ghys' new Default UI.

@5iver 5iver closed this as completed Oct 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants