It appears that what you are referring to as “Scripting APIs” are not the same as what I have been referring to. The new rule engine is awesome, but it was developed with UI rules in mind, and it needs some effort to improve it’s almost complete lack of user support for scripted automation. This is why the helper libraries were created. They are very good at sandboxing and then testing functionality that should be built into OH. Once proven, this functionality needs to be moved into Java.
To improve the NGRE, we should build out the layers of abstraction between the user and the rule engine through ScriptExtensions, Actions, and a new Scripting API (in Java) that can be used by scripts launched with any flavor of ScriptEngine. This is what I have meant by the Scripting API replacing the functionality of the helper libraries. Language specific libraries will no longer be required for creating triggers and rules, accessing Actions, manipulating metadata, Items and Things, etc.
Completely refactoring the helper libraries at this time would not be worth it, and our efforts should be focused on implementing the helper library functionality in Java. Please don’t take me the wrong way… I’m thrilled that you are interested in scripted automation. I think it is just a matter of combining our efforts or we will be stepping all over each other.
What you have put together has diverged significantly from the Jython and JS helper libraries and I’m beginning to doubt that it will be able to be integrated, which is a shame. Early on, I tried to lead you down the path of developing the Scripting API, rather than expanding the functionality of the JS HLs. What you have now is a completely separate implementation of helper libraries specifically for JavaScript.
I disagree. For OH3, as I’ve mentioned previously, I plan to rename the /automation/jsr223/ directory to /automation/scripts/ or potentially remove it completely. Any references to jsr223 in the docs should be replaced with scripted automation.
And Community too! Potentially! This will be driven by how the ExtensionService is implemented in OH3. I’m starting to think it would be best to package the libraries separately, possibly as individual bundles. There are pros and cons to both, but I do not want to discuss this here (better in GH).
Either way, by packaging the libraries, rule templates can be distributed with Scripted Actions and Conditions that make use of those libraries. Scripted automation is included in the UI (REST API) rules. One of our main goals should be to advance OH automation should be to facilitate custom library and script writers in their efforts to build rule templates for use in UI rules, so that OH has a robust archive of rule templates that are easily shared and collaborated on. The helper libraries are a big step forward, but the Scripting API will be even more useful.
No. Core and Community scripts and libraries are not to be modified except through a PR. In order to develop them, they need to be first copied to Personal. These libraries have to be standardized so that they can be reusable and supportable. Core will fade into the Scripting API, but Community will remain included in a custom ScriptEngineFactory, a single separate bundle, or as individual bundles available through an ExtensionService.
The HL repo has examples of how to write custom scripts and the use of the libraries. Looking to the future, a fraction of users will use this information. A smaller fraction will develop rule templates that contain scripts using custom libraries. However, these rule templates will be shared through an ExtensionService and used by the vast majority of OH users in their UI rules.
It depends on what is using them. If they are for personal use, the libraries should go in /automation/lib/personal/, or wherever the user wants, with a symlink back to this directory, or with an entry in EXTRA_JAVA_OPTS to add it to the python.path. Third party libraries used by Community scripts or libraries go into the Community package. Look at the Esper and Autoremote packags for examples.
What do you mean by this? I’m assuming you are using terminology from the ECMAScript spec and are referring to ScriptExtensions?
I’m not following your meaning… I think. The Jython bundle only adds Jython, along with the Core and Community libraries, as an OSGi bundle. Other than the OGSi aspect, it all behaves the same as if Jython and the libraries were manually installed. I’m not sure what you mean by provided namespaces.
Assuming you mean ScriptExtensions, we should not discourage their use. This is the mechanism that will provide most, if not all, of the scripting API. It also allows scripts to store and share objects. What do you mean by “your sub-namespacing”?
When there are breaking changes, I will be renaming core.jsr223. But I’m in no hurry and have not decided what to rename it to. This may be the only core Jython HL that will not be able to be pulled into the Scripting API.
I suggest you read some of the history of the helper libraries…
Originally, they were in a package named openhab, which caused a lot of confusion and namespace ugliness. Core was chosen by consensus and aligns with the naming used by OH and a lot of other software, including Python. I don’t see this changing, but your welcome to bring it up as an issue in GH, which is where any feature requests for the helper libraries should be discussed.
I don’t understand what you mean by this. BTW, Python imports look like…
from package.subpackage.module import function
I think you need some more time with Python 
! As for the modifications to ScriptExtensions, I do not see a need for these changes and will respond in GH during my review.
In the last couple months, you’ve had a flurry of development around scripted automation and the helper libraries (thank you!), but my time is extremely limited. Your GraaljsScriptEngineFactory (still needing review) includes CommonJS, which is a step in a direction that I am not yet convinced is needed for the helper libraries. I feel it is very important to keep the helper library functionality as similar as possible between languages in order to ease their absorption into OH as the scripted automation functionality is expanded. The libraries that you are implementing have diverged so much from the Jython HLs, that I’m having trouble imagining them fitting in the helper library repo. The current JS HLs are awaiting JDK9 and ES6 support. The GraaljsScriptEngineFactory could expedite this. Either way, and as I’ve said mseveral times before, the triggers.js and rules.js libraries will be built out to match the Jython versions, or a Scripting API will be built out for them… I’m not sure which will come first!
NO!!! A week before a major release is a horrible time for this, unless you are planning to not have any developer input! You should all be out testing! 
There have been module and script name changes, and the directory structure is all new and heavily thought out. However, I will be making some changes in OH3 and will open an issue in GH to discuss them when the timing is better. Changing the directory structure is a huge undertaking, starting with getting consensus!
How so? Both bundles make use of the javax.script APIs. This is our only option until we have an implementation of GraalVM.
In less than a week, the NGRE will no longer be labelled experimental! There have also not been any breaking changes since S1310, back in July 2018. Users may think of it as experimental, but the devs do not treat it as such. There will be a big focus on automation for OH3.