-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
[GraalJS] Add support for ES6+ to automation via GraalJS #6399
Conversation
This pull request has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/graalvm-for-automation/84116/13 |
Travis tests were successfulHey @jpg0, |
This pull request has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/fluent-js-api-for-rules/85524/1 |
This is +83,314 lines of added code. The chance for this going through review is low to be honest. If you have further ideas to cut down on lines please apply those. A regular binding has around 1.5k SLOC. |
Signed-off-by: Jonathan Gilbert <jpg@trillica.com>
Travis tests were successfulHey @jpg0, |
@davidgraeff you're completely right; apologies for that. The large amount of code was testing for specific edge-cases in loading 3rd party libraries' modules. I've removed it entirely as it's mostly tested elsewhere via mocks. Down to a much more manageable size. |
Travis tests were successfulHey @jpg0, |
Thanks @jpg0, 2200 LoC look much better than before ;-) I am wondering, whether this is the right repo for the PR, though. We don't have a add-on category for scripting engines and it probably does not make much sense to introduce such a category. As you mention, this is rather a replacement for the Nashorn integration, so it should be considered a core component (maybe one that isn't installed by default due to its size, though). @openhab/core-maintainers What's your view on this? Where should such code best live? |
I just realised that somehow an old factory file was left in there which broke classloading order. I've push a new commit to fix this (and also simplified logging). |
Signed-off-by: Jonathan Gilbert <jpg@trillica.com>
Travis tests were successfulHey @jpg0, |
1 similar comment
Travis tests were successfulHey @jpg0, |
...in/java/org/openhab/automation/module/script/graaljs/commonjs/internal/FilesystemFolder.java
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's your view on this? Where should such code best live?
IMO it depends on how much other scripting engines we expect to become part of OH 2 in the future. In general it is an extension for the automation engine. On the short run it would be be okay to move it to OHC but in the long run ... Does anything else speak against a new add-on category? Or is this another topic for OH 3 architecture?
All these scripting engines would be useful for OHC derivatives. But it will have a big impact on the download size if they are all included by default. I see that several of the Maven dependencies are 10MB or more. |
I plan to submit a similar PR for a Jython this weekend (:tada:). Once closer to OH3, I plan to open an issue to discuss the possibility of removing the rule engines, scripted automation, script engine factories, module types, rule templates, etc. from OHC and create a new repo for them. Due to this, my suggestion is to put everything automation related into OHC for now. This is where I've built the Jython script engine factory, although it also worked as an addon. Jython is ~40MB. Once I have the PR in for Jython, I plan to review this PR, which I see several issues with. |
Are there any issues that I can begin to work on now? |
Travis tests have failedHey @jpg0, 2nd BuildExpand here
|
@martinvw I formatted using the default Eclipse formatter, and it used tabs instead of spaces, which has failed the build. Is there a specific formatter documented or downloadable anywhere, or should I just switch tabs to (4x) spaces? Edit: I have now reformatted as Eclipse w/o tabs. |
Signed-off-by: Jonathan Gilbert <jpg@trillica.com>
Travis tests were successfulHey @jpg0, |
Signed-off-by: Jonathan Gilbert <jpg@trillica.com>
Travis tests were successfulHey @jpg0, |
I have two features that I had added after opening this PR:
Currently these are not included; I'm happy to keep going on this PR without them (I'll submit as subsequent ones), but if you'd prefer to include them, let me know. |
2.5.x is our current working branch for openhab-addons. Please change your PR to merge to that branch instead. |
TBH I've assumed that this PR is dead as it's been open for 4 months. My code has moved on as well as OH, although I know that it's still compatible as I'm still actively using and maintaining it. If this PR has a hope of actually being merged I'm happy to update, but if it's going nowhere then I can close it. |
@jpg0 Definitely not dead or forgotten! |
@cpmeister This PR is definitely for 3.0 and not 2.5, so having the PR against master is just fine in this case! |
@kaikreuzer I'll update this PR once that decision has been made, as it will affect this code too. There are quite a few improvements since this was originally submitted. |
Thanks 👍 |
As I mentioned much much earlier, there are several issues that I see in this PR that I believe should be addressed before it is merged. The openhab-addons and openhab-core maintainers may feel differently.
|
Thanks for letting me know the issues that you found! I'll respond here whilst I've got a second...
Anyway, I'll look forward to the full review. |
For your replacement PR, it would be great if you could go directly for the namespace suggested in openhab/openhab-core#1319 (comment). |
Sure! |
Superceded by #8441 I'll close this and work on that one; there have been more changes and the add-on is now more mature, but requires some changes in code it depends on. |
Signed-off-by: Jonathan Gilbert jpg@trillica.com
Bundle to add ES6+ support for automation via GraalJS
OSGi bundle to provide a GraalJS runtime for automation before Graal is bundled with the JDK (e.g. using Java 8 in this case). GraalJS is significantly more capable than Nashorn, which now deprecated.
This is a drop-in replacement for Nashorn, the only incompatibilities potentially being existing scripts which use Nashorn-specific features (which will need to be addressed at some point regardless). It does NOT replace the scripting engine for transformations (although this would be relatively straightforward to add).
Note that this bundle also enables CommonJS module support by default (although can be disabled), and therefore allows
npm
-installation of most of the existing available 3rd party JS libraries.Discussion originally started here: https://community.openhab.org/t/graalvm-for-automation/84116/11
Binary available for testing.