Background: Some time ago, I built a LED clock which is “smart” in the sense that it has a frontend application to set colors etc ( https://github.com/hakan42/chronos ). via a REST interface (MQTT coming soon). Why? Why not? I’m a hacker / maker / software engineer
All in all, even after I write up a proper instructable and document stuff, I would be happy if a second person on this world built a similiar clock.
My next goal is tightly integrating that clock with my OH2 installation, so I rules like “flash LED ring white when it is time to run to the public transportation, but if it is raining, flash the LED ring red to signal that I should take the car instead”.
I would love to do the second part in a proper binding so I have a tighter integration compared to what is possible via rules and HTTP calls.
Contributing the binding to the OH2 repository would give it more visibility, perhaps giving other people to build similiar things. But I would be bound by the development process of the OH2 project (pull requests, reviews etc.). Actually a good thing, but I would put additional workload on @Kai who is swamped already.
Keeping just my binding in a seperated git repository would allow me to work at my own speed (or slowness as it might be) but would run the risk that I get cut off from the main development of OH2 and smarthome core. Also, as far as I know, there is no maven repository holding the artifacts yet.
What would be the opinion of the community and the benevolent dictator(s) on this question?
You are right, bindings like the one you describe are probably nothing I would want to worry about reviewing and including it in the “main” repository. Nonetheless, having them distributed all over Github makes it almost impossible to find (out about) them.
In the context of openHAB 2, I am currently thinking about restructuring the whole repo setup, since the openHAB 2 distribution now already contains artifacts from openHAB 1, openHAB 2 and Eclipse SmartHome alike. Also, the new Karaf-based distribution that I am working on with @maggu2810 means that there won’t be any “addons.zip” file anymore in the future.
I am not yet clear on the final structure, but I will take care that 3rd-party-separately-versioned-addons will find there place in it. For the time being, I think it is best if you simply maintain it in your own repository.
Timewise, I think I will go and address this after the openHAB 2 beta release, which I tentatively plan for end of this year. So ping me in Q1/2016 about it again, if you don’t see any news
There is the setup like Jenkins does it, with non-official addons / plugins being cloned into an “organization” called jenkinsci. What I like most there is that they have also a cloudbees instance which provides build / testing for additional plugins.
Then there is the addon registry for Kerbal Space Program, which just provides a registry to download sites which can be distributed all over the internet. This could help with the visibility problem, but in the end, they rebuilt there what we already have with maven. Also, no CI help for the addons.
