Moving the library to reside under the openHAB project

[jimtng]

@boc-tothefuture what are your thoughts regarding moving the openhab-scripting library to be under the openhab project, in the same manner as the js-scripting library?

[jimtng]

@ccutrer feel free to share your thoughts as well, thanks.

[boc-tothefuture]

I am not philosophically opposed. I would need to understand the requirements with my employer if it were to move to a different repo.

[ccutrer]

I really like how it's structured now. Both in flexibility of releasing independently of OpenHAB, as well as ability to point to a development copy and quickly iterate without having to build a JAR and uninstall old/install new/break my openhab while this is in progress.

[jimtng]

I'd imagine that the development process wouldn't change. The library would still be published via gem to rubygems, so it can be updated any time, maintaining the semver convention, and not at all tied to openhab's release schedule.

It wouldn't be "bundled" into the jrubyscripting addon.

The only change perhaps would be that the docs currently in https://boc-tothefuture.github.io/openhab-jruby/ might then live under openhab.org domain or be absorbed into openhab.org/docs/ somehow.

[boc-tothefuture]

Out of curiosity is this a reaction to this post?

[ccutrer]

Maybe we should consider defaulting the gem list of the addon to install this gem?

[jimtng]

I hadn't actually read that post, but he has raised similar concerns in other posts. He does have a point though. Jython's helper library was hosted in 5iver's repo and it was abandoned. How could we deal with a similar situation for this library?

The other points below are minor:

Maybe we should consider defaulting the gem list of the addon to install this gem?

This too would be an advantage. I don't see anyone using the jrubyscripting addon without using this gem, so why not make it easier.

[ccutrer]

It's not just that the Jython helper library is abandoned. The entire Jython project is abandoned, making it all but impossible for a Jython plugin to be maintained. JRuby, on the other hand, is alive and well. It lags behind MRI, but not impossibly so. And I've been impressed by the responsiveness of that team for the few times I've interacted with them, giving me a positive outlook for the future.

I like the idea of working towards the gem being the "blessed" way to use the addon. Maybe just getting the repo hosted under the OpenHAB GitHub org rather, but still as a separate repo would be a good direction? There is precedent for this - the zwave binding is its own repo.

[boc-tothefuture]

Initially I didn't want to put the gem as a default into the add-on because there were concerns raised when I initially presented the DSL that it was too different from Jython and others which was going to cause problems. I felt that by having a hard separation of the binding and the gem that during the binding review that no one could raise an objection to the gems somewhat different philosophy on how to handle OpenHab's, in my opinion, quirks. (Not that this gem didn't create its own quirks..).

At this point, I would not be opposed to installing the gem by default, and letting people opt out of it.

[boc-tothefuture]

I hadn't actually read that post, but he has raised similar concerns in other posts. He does have a point though. Jython's helper library was hosted in 5iver's repo and it was abandoned. How could we deal with a similar situation for this library?

Moving it to another repo doesn't fix the problem though? Someone could have forked his repo and kept Jython helper alive if they had wanted to. If we merged this into the OpenHAB binding and we all stop working on it then it would all be just as abandoned.