Add a bundle for Jython

[5iver]

In order to be used with JSR223, a user needs to install Jython, add it to the classpath, and tell Java where to find the libraries. This is documented here. We should add a bundle that will install Jython for the user. Most people that had issues with the install had trouble configuring the EXTRA_JAVA_OPTS.

• A full install or the standalone jar could be used. I think the bundle should just pull down the standalone jar, but leave the option available for someone to reconfigure the location of Jython, so that a full install can be used. This might be best as an expert option.
• Options should also be available to configure the path (search path for modules) and home (alternative search path) directories.
• Jython 2.7.1 is currently the latest, but there are known bugs, which cause issues in OH. Jython 2.7.0 is much more stable, so I think it is best to use this, until 2.7.2 is released. Or we could compile our own 2.7.1.patch release.
• Helper libraries could be included, but IMO this can be a feature for later.

Questions:

1. What directory should the standalone jar be saved to, and what should be the default home and path? The current instructions use...
   OPENHAB_CONF/automation/jython/jython-standalone-2.7.0.jar
   home=OPENHAB_CONF/automation/jython
   path=OPENHAB_CONF/automation/lib/python.
   This will work with the current helper libraries, but if we want to change these, now would be the time.
2. Should the bundle modify EXTRA_JAVA_OPTS, or is there another way? If EXTRA_JAVA_OPTS has already been manually modified for use with Jython, should it be left alone or updated?
3. An OH restart will be needed after this bundle is installed, although I guess that depends on how the properties are set. How should this be handled? A message after saving the configuration?
4. What type of bundle is this (binding, io, etc.)?

[davidgraeff]

4. What type of bundle is this (binding, io, etc.)?

I think it matches the category "extensionservice". It might even make sense to implement exactly that: An extensionservice (eclipse marketplace is such one) for additional JSR223 providers.

Another one or the same could be used to provide additional JSR223 libraries for users.

3. An OH restart will be needed after this bundle is installed

It doesn't need to restart if we include the target directories to the classpath, does it? If you for example download into the addons directory, you do not need a restart for example.

[5iver]

Thank you for replying! I've been working on #519, but have spent most of the day trying to get a working IDE to debug it. I plan to work in this next. The OP was just thoughts/notes, mainly to show the intent and see if anyone would want to be involved.

I think it matches the category "extensionservice".

Category... is that the official term I've been looking for!? 😄 For now, I'm only planning on the Jython and Groovy jars. Helper libraries make sense as separate bundles, to leave the option available for someone to use their own, and so that more than one set could be made available. Although, my plan is to move much of this functionality into an API that can be used by any JSR223 language.

I'll take a look at the Marketplace bundle to see if it could be used as a temple.

It doesn't need to restart if we include the target directories to the classpath, does it?

Currently, we are using EXTRA_JAVA_OPTS to add Jython to the classpath, which requires a restart. Is /addoins/ in the classpath? That may get Jython into the classpath, but home and path will also need to be set so that Jython knows where to find the libraries. IDK if that can be done on the fly, but hopefully a helpful Java dev can help with that, before I start digging into it.

[kaikreuzer]

@openhab-5iver Why did you close this issue? Do we have any PR similar to #8516 for Jython in this repo? What is imho needed is porting #7208 to the main branch - I'd therefore suggest to leave this issue open.

[kaikreuzer]

@5iver To come back on this: I think it would be great to have the JythonScriptEngineFactory included in the 3.0 release, i.e. the work you did in #7208. The PR would imho look pretty similar to #8772 for Groovy and hopefully be pretty straight-forward or am I missing anything?

[5iver]

I think it would be great to have the JythonScriptEngineFactory included in the 3.0 release, i.e. the work you did in #7208.

Me too, but even better, let's get them into 2.5.x by merging #7208 and #7210 for inclusion in 2.5.11. It would then be very easy to add them into OH3.

As I have communicated several times in the forum, I will be providing add-ons for Jython. These are currently available in the Eclipse IoT Marketplace for 2.5.x. I plan to finalize them and add some posts in the forum, hopefully this weekend. In hindsight, I should have added them to the marketplace a year ago, before submitting my PRs, but I had faith that they would be merged into OH. People could have been using them for over a year now. After all of the effort I have put into automation, I've been burned and I have learned my lesson.

I have also communicated several times that once the 2.5.x add-ons are complete, I will provide OH3 versions the the Jython, Jython helper libraries, and Jython TransformationService. The ports themselves did not take much effort at all. As you are probably aware, there are already at least a couple OH3 Jython add-ons already floating around. However, the automation code is very fragile. With all of the recent PRs, the update to jdk11, and the lack of a maintainer to provide oversight, I have doubts that everything will work as it did in OH2. The additional testing alone will take quite a bit of effort, especially since I would be the one supporting it on the front lines.

Also in the works, I have created add-ons for jRuby, Groovy, Kotlin, Scala, and the JavaScript helper libraries (which have been updated to be more aligned with the Jython HLs).

[kaikreuzer]

2.5.x by merging #7208 and #7210

Both those PRs are not in a mergeable state (and even closed), so I very much hope you didn't wait until now for them to be merged.

Your work seems to focus around writing rules in those languages (and thus also require helper libraries).
My question above was much much simpler than that, i.e. adding Jython as a script engine, so that it can e.g. be used within script actions in the UI, just as we have it for DSL, JS and Groovy already.

@wborn Since you did the Groovy add-on, would you also be able to provide a Jython script engine add-on that we could still squeeze into 3.0? Once the "full scripted rule support" work of @5iver is created, tested and stable, this can then be targeted for 3.1.

[hmerk]

closed, as related PR was merged