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 Add JythonScriptEngineFactory by 5iver · Pull Request #7208 · openhab/openhab-addons · GitHub 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 Add JythonScriptEngineFactory by 5iver · Pull Request #7208 · openhab/openhab-addons · GitHub 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
Actually I got the impression scripting using JSR233 would be the future of rule-programming (vs. specifying rules somewhere) in openHAB. Your statement doesn’t sound like this and I am probably wrong? Is there a longer term / strategic direction where openHAB will go? I invested heavily in migrating from DSL to Jython for four reasons: #1 I had plenty of performance issues using DSL for calculating complex algorithms; #2 I found DSL not well designed when it comes to parallel processing (frequently occurring for rules with multiple triggers); #3 I prefer to use some mainstream language and #4 I thought it is what openHAB is heading to. I’m happy with OH and Jython now.
2 Likes
JSR223 scripting is not only about jython, you can also use Javascript, groovy and possibly other languages. I myself use Javascript, which is already available.
1 Like
Exactly - the idea was to have those languages side-by-side so that users can choose the one they know/prefer. JS and Groovy are imho even more natural choices on a JVM, especially as there are unanswered concerns about the future support of Jython on a JVM. It would thus be imho foolish to make openHAB’s future 100% dependent on that.
3 Likes
You mean like openHAB releases rely on you? 
Ih the 2 posts in this thread you never once offered to help. You therefore came across as condescending & dictatorial to Scott & I as Americans.
Sorry for misinterpreting your intentions.
We are living on one world. Let’s solve problems together not with political statements.
3 Likes
It was meant as more cultural differences, not political.
1 Like
Right, since they do not rely on me. I am currently doing this work (and a million other things), but if there is a period in the future where I am busy with other projects and won’t spend a minute for openHAB anymore, you can rest assured that others are able to do the releases as well and openHAB can further evolve.
I wrote: “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.”
I am sorry if this wasn’t perceived as a friendly, helping, collaborating and constructive statement, but as “condescending & dictatorial”. This might then indeed be a lack of my skills in bridging cultural differences.
That was meant as humorous since you mentioned spreading out the releases to keep you busy.
That is not offering assistance writing the PR. @5iver responded he is busy mow with other things.
He has offered to assist somebody else from the community to write the PR. If nobody else wants to do that it is not Scott’s fault.
1 Like
We can also help with porting the PR to OH3 and see how well that works. But it can be perceived as a hostile take over.
Sorry, being stressed it isn’t easy to identify humor these days - thanks for trying .
Yes, that was exactly what I thought and why I actually asked him whether he wants to do it himself (and might already have started) or if he is ok when somebody else takes it over.
If we now agree that his statements can be taken that he is fine with it, that sounds good.
1 Like