Migrate repo to OH-Jython-Scripters?

[5iver]

@lewie , would you be interested in migrating your repo, so that there is one location for all OH JSR223 helper libraries? The name of the organization could change to OH-Scripters, and then have separate repos for each language. The other repos you see are in progress of being absorbed back into openhab2-jython. The directory structure could be kept consistent too. You would of course be added as a maintainer for the Javascript repo, so there shouldn't be any change in accessibility/maintainability/freedom for you.

I'm asking because I have been researching ScriptExtensions, to be able to implement global variables within a script engine. My main driver was to get this working with JS, since it is/will be the main language used for scripted actions (I recently submitted a PR that adds Jython and Groovy) used in rules created in Paper UI. So, I've been looking into your helper libraries, and have converted part of the core.osgi Jython package to JS. This is functional, and I have been able to register a service using JS. Next, I will migrate JythonExtensionProvider to JS. I would like to share these, which brought me to ask about your repo.

[Hilbrand]

Something to consider could be to build a java addons that includes the helper libraries. That way these helpers are available in any language supported by jsr223 and only specific language parts (like the annotations in python) have to be maintained in the language specific library. I did some prototyping on it: https://github.com/Hilbrand/openhab2-addons/tree/ngre_ext
If such an addon would be developed it could also be added to the official distribution or included in the core.

[5iver]

Very nice, @Hilbrand! I actually had another paragraph in my original post here about something similar, but deleted it because I was rambling off topic. But discussions have come up in a few places about the helper library functionality being built into an API, scriptExtensions, and actions. That way they can be used by any JSR223 language, and some of the functionality could even be used in rules created through JSON or the REST API. For example, when the OH1 LogAction is migrated to OH2, that will eliminate the need for one of the Jython libraries. I really don't see addons being the right way to go for this though. I have to get Jython/Groovy scripted Actions (haven't figured out the UI piece yet) and Jython/Groovy bundles wrapped up, and knock off a few of the existing automation issues before I'll be getting involved in that. Glad to see you might be interested!

Until then, I'd like to get all the libraries in one place, and with similar functionality. It will also be nice to have a central place to store Templates too, which will become language agnostic once I get this other stuff in..

[Hilbrand]

Yes I think it would be nice to have all libraries in one place. For templates, your referring to rule templates? I think it would be nice to have some kind of market place concept were users can simply install templates from within their installation.
Regarding addons. I used it somewhat generic. But what I meant: addon as in something that can be installed by the user, like a binding. But some parts should just be parts of the core and available by default. So maybe an 'addon' is not needed, only for very specific or new stuff.

[rkoshak]

I'll agree with the above. The JSR223 languages will become the "default" for Rules development. Part of making that happen will include:

• centralizing the helper libraries so they can take advantage of synergies like what Hilbrand mentions
• distributing the libraries as part of the OH, no separate installation
• a soft standardization across all the languages for how the helper libraries work

To achieve these goals I agree with Scott, we need to get all the helper libraries in one place.

[lewie]

@openhab-5iver, @Hilbrand, @rkoshak

Yeah, yeah, yeah, you're all right! Of course I want this too in one right place. I am happy to have you with me, who also appreciate the potential of JSR223 for openHAB so highly.

But I would like to hand over as clean a house as possible! ;-)

Regarding the move of eclipse.smarthome, I still don't have access to the following required classes (Especially the not commented ones are important):
https://github.com/openhab/openhab-core/tree/master/bundles/org.openhab.core.automation/src/main/java/org/openhab/core/automation/internal/module/handler

org.openhab.core.automation.internal.module.handler.ChannelEventTriggerHandler	
org.openhab.core.automation.internal.module.handler.CompareConditionHandler	
org.openhab.core.automation.internal.module.handler.ItemCommandTriggerHandler	
org.openhab.core.automation.internal.module.handler.ItemStateConditionHandler	
org.openhab.core.automation.internal.module.handler.ItemStateTriggerHandler	
org.openhab.core.automation.internal.module.handler.GenericCronTriggerHandler	
//org.openhab.core.automation.internal.module.handler.GenericEventConditionHandler	
//org.openhab.core.automation.internal.module.handler.GenericEventTriggerHandler	
//org.openhab.core.automation.internal.module.handler.ItemCommandActionHandler	
//org.openhab.core.automation.internal.module.handler.RuleEnablementActionHandler	
//org.openhab.core.automation.internal.module.handler.RunRuleActionHandler	
//org.openhab.core.automation.internal.module.handler.DayOfWeekConditionHandler	
//org.openhab.core.automation.internal.module.handler.TimeOfDayTriggerHandler	

Without, triggersAndConditions.js will not work with JS.

Do you have any idea why that is?

When everything works again, and cleaned up a bit, I will copy as "oh-javascript" to "openHAB Scripters".
@openhab-5iver, are you renaming the repository and giving me access as described above?

Would that be okay? :-)

[5iver]

Of course I want this too in one right place. I am happy to have you with me, who also appreciate the potential of JSR223 for openHAB so highly.

👍!!!!!

Regarding the move of eclipse.smarthome, I still don't have access to the following required classes

I didn't notice this when testing to see if the DynamicImport PR actually returned things to normal. The Jython helper libraries do not use them. In ESH, these classes were not in internal packages, but when reintegrated, they got moved into internal packages. Internal packages are specifically excluded from Export-Package, and show up in Private-Package in the MANFEST.MF. So, even the DynamicImport will not help for these. It would be interesting to ask Markus why these were moved to internal.

However, it appears as though you are just using these to pull out the TypeUID. In Jython, we're just using strings for the TypeUIDs. Would this be an acceptable alternative?

@openhab-5iver, are you renaming the repository and giving me access as described above?

Yes, now that you have replied! 😄 I will need to get some approvals for changing the organization name and bringing you in as a maintainer, but I have no doubt that everyone will agree. I'll then setup the repos and give you access. My preference would be to maintain the same directory structure, so I'll setup what I think it should look like for JS, but we can discuss/modify when you are ready to get the files migrated into the repo.

As for repo names, I was thinking of just using the language names, e.g. jython, javascript, groovy, etc. The openhab2-jython repo name will need to change soon anyhow. But would ecmascipt be more accurate than javascript? In openhab/openhab-core#635, I have used ECMAScript, as that is how the ScriptEngineFactory identifies it.

🚀

[lewie]

@openhab-5iver,
yes, we can use Strings instead the hole classes. This version works with org.openhab.core and I would copy that to openHAB Scripters. ;-)

It is helpful, but really really experimental in this stage!

Edit 20190429: Have forgotten the Link. This Branch works with org.openhab.core:
https://github.com/lewie/openhab2-javascript/tree/smarthome-To-openhab.core

[lewie]

@openhab-5iver,

But would ecmascipt be more accurate than javascript? In openhab/openhab-core#635, I have used ECMAScript, as that is how the ScriptEngineFactory identifies it.

https://en.wikipedia.org/wiki/ECMAScript
ECMAScript is the name of the current standard. Generic term remains JavaScript

[Confectrician]

Hi all,

I know you are waiting for dependiencies to be fixed.
I just wanted to throw in my offer to help.

JSR with javascript, will be my way of defining rules in the future, so i would be glad to help get some progress with you guys together, when the eclipse smarthome move has been completed and imrpovements can be made. 🙂

BR
Jerome

[5iver]

I got a thumbs up to migrate JS into OH-Scripters. Here's my current priority list, so I will probably get to this by next weekend. Although, I'm seriously considering the possibility of not using separate repos and just having the one. This is likely how it would end up if/when moved to an official OH repo, and I've pretty much convinced myself that this will be the best approach.

[Confectrician]

So you keep us informed, when there are updates?

[5iver]

Absolutely!

[5iver]

@lewie and @Confectrician, openhab-scripters/openhab-helper-libraries#94 is complete and we're ready to add in the Javascript libraries. We'll need to figure out what permission levels are needed/wanted, but we can discuss that in the new repo.