How to Setup Jython

Permissions, EXTRA_JAVA_OPTS, the jar in the right directory, and a restart is all there is. The logging recommended in the installation instructions will provide all of the relevant logging. If you post a log from startup, I might be able to spot something. Are you running in docker? IIRC, you had issues the first time. Do you recall what they were?

Checked all of that. While I’d really love to figure out why the install didn’t work out I have no idea what else to look for.In the meantime I’ve disabled EXTRA_JAVA_OPTS and deployed the beta addon and this time it works. Is there anything wrong or unfinished with that ? If no, why don’t you make it the recommended solution ? It’s simpler than all those manual steps.

Not really. I believe it was a wrong path in EXTRA_JAVA_OPTS but I’m not sure any more.
This time that’s not the problem however.

No. The jar has not changed for about a year, so there’s nothing wrong with it :slight_smile:! There have been some significant changes that went into the add-on though, like being split into two, but they both have been rejected (ignored and unmerged) from all of the 2.5.x releases and are currently both closed. I have some significant updates for the libraries, some already merged, that I planned to include before the helper library add-on was merged. I’m always updating the core and community libraries.

That was the plan. I have a documentation update that I’ve been waiting to push that changes the installation to use the official Jython add-ons. After a year of fruitlessly trying to get them merged, it is clear that it will never be allowed, making you question what “first class citizen” means.

1 Like

Ugh, that’s frustrating and not how it should be. @Kai do you listen and could have a look please?
I’d consider (a single, tested) Python integration to be of utmost importance to OH’s future given that more and more people move to Jython to get rid of various DSL related issues (and probably even more would like to).
And given Scott is AFAIK the only person to drive this, you shouldn’t frustrate let alone ignore him.

6 Likes

I think there must have been some tremendous misunderstanding on both sides then. It definitely isn’t the case that anything was rejected or ignored.
I was under the impression that @5iver is working on https://github.com/openhab/openhab-addons/pull/7208 and the main reason why it was considered work-in-progress and thus not being merged is that it does not yet comply with the add-on naming convention. Adding and dealing with the helper libraries was clearly a second step after that.

The reason why the PRs are closed is that Github automatically did that when we rewrote the history of that repo - this happened to many PRs and I hope this didn’t cause anyone to think that we simply close PRs without any further comments - I tried to make it clear to everyone through the automatic migration comment.
I’m thus very happy to see a PR with the migrated code (and adapted to the naming convention) and will do my best to very quickly help reviewing and merging it.

10 Likes

That is a complete fabrication and absolutely not true! The following list is not complete, but it clearly illustrates a pattern of how you and the maintainers have ignored and blocked my contributions. Because of this, I have no PRs merged into OH 3.0.0, even though I had planned for many of them. So much for automation being a big part of OH3! I get it… this not openHAB, but kaiHAB… but when dictators are not benevolent and treat contributors in this way, they doom the entire project.

  • The original issue requesting direction for adding a Jython add-on was created almost 2 years ago. I had asked many questions in hope of getting some feedback and direction on how to implement an add-on like this. This was completely ignored except for a single comment.
  • The original Jython and helper library combo PR was submitted with ample time to be included in OH 2.5.0, but it was ignored until there was no time left to include it in the release.
  • My issue to discuss separating automation from OHC was excruciatingly slow and continuously offtrack. Most of the maintainers ignored the discussion completely, even though it went on for seven months. Removing all of the side discussions, the outcome of the issue itself boiled down to me, compromising in order to move things along, agreeing to separate automation from OHC, with the exception of the rule engine. Seven months later, the repository still has not been created for this to progress.
  • The Jython helper library add-on sat since March 23 without a single review.
  • An RFC to simply add OPENHAB_CONF/automation/ and rename the jsr223 directory has been ignored since July 15.
  • The Jython add-on has been held up waiting for a reply from you since July 18. For the last year, I have done everything I could possibly do to get this and the helper libraries included into a 2.5.x release. The only reason that there is not a Jython add-on in 2.5.9 is that you chose to put no effort into helping, but rather prevented it from being merged by not approving a simple naming convention and repeatedly dragging things out until it was too late. I see this as an intentional act to prevent the Jython add-ons from being included in a 2.5.x release.
  • @wborn submitted a PR for a Groovy add-on just yesterday. Three hours later, it was approved, even without an agreement on what the namespaces should be or the repository that should be used for these types of add-ons. Hmmm… three hours vs one year… would that be ignored or rejected? It is great that someone else is looking into this sort of thing, especially someone like Wouter, but I have communicated several times that I have been waiting for the Jython add-on to be merged before I submitted add-ons for Groovy, jRuby, and Kotlin. Ignored or rejected?

it is unfortunate that you would wait until now to offer your assistance. Why wouldn’t you have helped over the last two years, while I struggled to move this along? Or the last year, to get the PRs into 2.5.x? Something has obviously changed to make you want to help now. After all of this time, I can’t possibly believe that your newfound enthusiasm and willingness to help get the Jython add-ons merged is truly genuine.

The first thing you would need to do is to create a repository for automation. Next, respond to my question about the naming convention for the namespaces.

My time is currently committed to another project that also has an upcoming release. However, I will continue to do everything I can to advance automation and get add-ons for scripting languages and helper libraries into the hands of the community.

19 Likes

For my part, i won’t bother moving over to OH3 until @5iver’s valuable contributions to scripting are being merged :slight_smile: What I have tried from his work works almost without problems and I am convinced that the few remaining problems are due to the circumstance that his code is not being appropriately reviewed and integrated. I am using JSR scripting (Jython) for at least two years now and I am sad to see this great opportunity of creating automation rules being kept an outsider for all this time.

8 Likes

I agree with that sentiment. What gives me hope is I think better things are coming.

I envy your optimism but in my opinion things will be mainly be different. :wink:

1 Like

I did not know/remember you had planned something for Groovy too. But your Jython PR definitly helped me and I also incorporated the review comments on it in my PR to get it merged quickly.

Meanwhile I also fixed rules from files not properly loading (#1725) and added an extension type for automation add-ons. These PRs should also help with adding a working and installable Jython Scripting add-on in OH3. So the automation add-ons train is definitely rolling. If there are still some issues with getting Jython working in OH3 please let me know.

Personally I think openhab-addons is currently the right repo to add these kind of add-ons. It saves us from the work of having to setup a new repo and infra (with overhead) and it comes with nice benefits of already having a lot of contributors/maintainers who can help reviewing so that prevents bottlenecks or single points of failure. We can always decide to restructure repos after we have seen how this new add-on type evolves.

3 Likes

I thought the reason OH was open source was so people were free to extend its functionality without the requirement it be included in the official repos. That is the way other competing smart home projects operate.

In the openHAB Github project there are many repositories, e.g. openhab-core, openhab-docs, openhab-addons, etc… Each repository has its own infrastructure, contributors and maintainers.
Scott’s suggestion was to create an openhab-automation repository where these type of addons should live. Wouter’s suggestion is to keep them in the current openhab-addons repository where the infrastructure is already in place and other contributors and maintainers can peer review the code before it is being merged.

Same as me. I had already merged 90% of my rules from DSLR to Jython new rule engine as it is mutch better plus information was that OH3 will use it by default. So I won’t make any further effort into OH3 till new rule engine will be avaiable. I have several automation running. I have 150+ things connected to each other from alarm system till heating, lighting. We need it!

4 Likes

I don’t think these kinds of accusations are helpful for anybody here. Again, as already stated above, I guess there must have been some misunderstandings and at least I am sorry, if this was the case. Again, for me the PR was work in progress and I didn’t see any progress since my last comment in July. Likewise, your RfC seemed stale since July as the raised concerns where never answered in any way. Why creating an RfC, but then ignoring the comments?

it is unfortunate that you would wait until now to offer your assistance.

I don’t know why you blame me although I was more or less the only one actively discussing your PRs and issues and suggesting solutions?

The only reason that there is not a Jython add-on in 2.5.9 is that you chose to put no effort into helping, but rather prevented it from being merged by not approving a simple naming convention

It seems we are going in circles here. I suggested a bundle name of org.openhab.automation.jythonscripting and said that I am fine with any other speaking id instead of jythonscripting, you mentioned org.openhab.automation.scriptenginefactoryjython, but also said that you’d be fine to adopt any other id. So why is the bundle name in that PR today still org.openhab.automation.scriptenginefactory.jython, which is not a valid one? All it takes is to refactor it to comply with the add-on naming convention of org.openhab.<addontype>.<id>.

@wborn submitted a PR for a Groovy add-on just yesterday. Three hours later, it was approved

Well, it applied exactly what had been discussed on the Jython PR and it looked exactly how I expected the Jython PR to look like. And yes, it should be that easy: Just rename the bundle to org.openhab.automation.jythonscripting (which imho now makes most sense to be inline with the JS and Groovy add-ons) and we should be good to merge.

I thought the reason OH was open source was so people were free to extend its functionality without the requirement it be included in the official repos.

Anybody is free to fork, modify and extend, but what is part of the official distro and is covered by the documentation also clearly resides in the official repositories.

So can we count on you to update https://github.com/openhab/openhab-addons/pull/7208 and get it merged for 3.0.0.M2?

1 Like

A very unpleasant situation, I, like many in this community, have been waiting for this unification for a very long time. I hope this situation will be resolved very soon.
@5iver you are a huge plus! very good work, it’s a pity, not appreciated by everyone. Thank you for not giving up so far!

13 Likes

While there may be misunderstandings or other problems within the openHAB maintainer-group, I think it is simply not true that @5iver’s work is not appreciated. I’m pretty sure that everybody thinks that the helper libraries and also the efforts to have a better - i.e. not manual - integration of Jython are a great step forward for the automation component of openHAB.

15 Likes

So I guess everybody is now simply waiting for an answer on that question above:

He already answered that if M2 is going to be released soon.

You cannot expect to dictate the schedules of volunteer developers.

If this is not the case, then tell me which option is better? What to strive for? There is a lot of discussion, for example for me, with a lack of understanding of the English language (only google translator), sometimes it is very difficult to understand the subtleties, as well as to formulate a question so that they would understand me correctly.
Question: for OpenHAB3, which way of writing the rules is preferable? Considering that for me, only the file option is considered.
PS In no case, I did not want to offend anyone, I respect any work done and any feedback and help from any member of the community, my problem remains one, Google translator does not clearly express my thoughts and some people can understand them differently.
Thanks!

Update!
I would like to add on this topic. Of all the topics in the openHAB community that I follow, in my opinion, one of the best in terms of support!
Firstly, the entry into the topic is very well documented, secondly, the instant support of the author, in the main topic, in the newly created ones! We have to admit that not many topics are supported as well.

2 Likes

I think you are not getting the point here. He claims it is my fault that Jython support for OH3 is missing, which is completely untrue. Instead, there has never been a PR for that and we are waiting since months for one. So who is forcing what on whom?

Btw, this is not about @5iver and me. It is about how the community can collaborate. PR reviews in openhab-addons work without me as there are other maintainers as well. Likewise, if Jython-support is such an important feature for many, it should not rely on a single person. So if @5iver does not have the time or will to work on it, it should be possible for somebody else to take https://github.com/openhab/openhab-addons/pull/7208 and make a mergeable PR for OH3 out of it. My question was therefore rather if he is working on it or if he’d want support from others (and I offered my help on that already).

5 Likes