That’s a catch22. If no bindings are written, then the API’s will never become final 
But I don’t think anyone blames you for the long delays. You are already putting in so much effort and there is only so much a person can do.
I’ll continue in the other thread.
I agree with @davy. Better have in there, have it break down if necessary, and then fix it. (that too will be free time well spent btw). I mean, all the API changes we had so far did bring good stuff to the bindings, no? 
K
Time to write or suggest a Maven tutorial for us mortals not doing code dev every day?
K
It is of today’s 2.0b1 announcement that I finally cached up, but why not adding a “contributions” distort for all the stuff that is not reviewed/approved/clean, with access for all the active add-on developers? Just a place to dump stuff, W.I.P and so forth? Something that can be extensively forked and so forth
I assume you are not aware how much time I spend on not breaking the API when doing changes to it, because I would otherwise have to adapt all the bindings that are out there already… Having less bindings makes it easier to do and communicate breaking changes that would potentially simplify and enhance the API.
I don’t think it will help the project if everybody does the code in different ways and only provides the binary at an untrusted location.
So for official tutorials, I prefer the idea of automatically building and deploying PRs, even if they are not merged.
Well, this is what a DVCS like git is all about. This place IS the openHAB repo and everyone has access to it and can do changes by forking it. The link to the forks is nicely provided in the PRs.
I rather meant, the new stuff that got introduced over time. I for one did not mind rewriting my bindings to adapt to new stuff in the API’s. You are right, in fact, little broke over time, but new great things came along
Honestly, me too, but what I meant is that we get an proliferation of dev.tools to use, the learning curve will get steeper for all those that are not pro-developers. I also prefer homogenous code
I know, but what I meant was a contributions repo (“distort” → predictive spellchecker mistake) on GitHub with access to all of us (e.g. without bottleneck of maintainers’ time), e.g. read and write access
K
Hello Folks,
I read this post and feel guilty after using OH for so long to support actively in the dev of it. I am trying to push it in my company to become more known.
But Iam also an old OSGi developer and already created a telematics plattform on OSGi with embedded Java. So I feel you @Kai if you speak about dependency management. I think there is a big need for a build server, where all the jobs could be automated.
I will try to set up a local instance and IDE of ESH and as soon I can walk alone, I would like to support in the OH2 area. As much my wife doesnt get it
BR, Mehmet
This thread is quite old but I didn’t find any newer one regarding this topic. I read your posts and understand the concerns of both sides.
First, I would like to add another major drawback of the current approach: As a user who is willing to experiment with addons that are under development and “living in the wild”, it’s just extremely hard to find them if they’re maintained in fork 645 of the openhab2-addons repository. In addition, there is no issue management available on GitHub for these kind of addons.
Coming back to the developer perspective, I think there should be a clear and fair path from how a developer should start with binding development to how he gets his addon into the officially maintained status. If the chances of the own addon of being taken over into the official repository are low (because of a small audience and limited maintainer resources), it’s not a good approach to mislead the developer to the (in my opinion awful) approach of using a fork (where there is no possibility of tracking issues etc.) and let him wait until the cows come home. In addition, if his addon maybe gets more popular later on, there should be be a good way of handing it over to the officially maintained repo.
I would like to bring two ideas up for discussion. I think they’re less invasive as the approaches previously discussed and take the requirements of all three stakeholder types (user, addon developer, maintainer) into consideration:
Idea #1
It would be good to have a best practice documentation for “not so important” addons that have low chances of ever being reviewed and taken over by a maintainer. Or also for addons that cannot be maintained in the official repository because of licensing concerns. Cherry on the cake would be to have clear criteria which addons are “important” and which not.
A good approach for addons “living in the wild” in my opionion: Seperate repository with nightly Travis builds to check whether they’re incompatible API changes. Example:
Idea #2
Regarding the repository structure I have the following idea: Carving every “officially maintained” addon to a seperate repository owned by the OpenHab project (like openhab/milight-binding). To keep them maintainable within the existing Maven structure and the current CI approach, the openhab2-addons repo could include them as Git submodules.
This approach would have several advantages in my opinion:
First, this would enable the project to nominate addon-specific maintainers which are known of having a good API understanding and being able to produce good-quality source code. I think there are quite talented maintainers out there who just do not have the time to take responsibility of the overall project.
Second, this would enable the possibility to manage addon-specific issues and PRs seperately (very important in my opinion, currently it’s just a mess!).
Third, it would make it possible for addon developers to start with a seperate repository which can be handed over to the OpenHab project later on (by using the “Transfer ownership” functionality and adding it as a submodule to openhab2-addons).
Last but not least I think the overhead for maintainers would be minimized (compared to the current approach on refactorings e.g. just the “git submodule foreach” would have to be prepended to the Git commands that are currently used and having a complete checkout is quite easy).