This is a huge step forward!
My thanks & kudos to @Kai and for everyone else that made it possible.
Hello!
I have build # 826.
Apt uptate:
All packages have the latest versions.
Where is # 827, # 828?
Earlier new assemblies looked here:
https://oss.jfrog.org/webapp/#/builds/openHAB-Distribution
Where can you see it now?
apt sources list:
deb JFrog unstable main
PS Why not show the assembly number in the paperUI?
Thank you.
1 Like
@Olymp You can also download the builds directly from Jenkins in case they fail to deploy to Artifactory. E.g. the IoT Marketplace also worked for me after downloading Build #835.
Imho, it would make sense to remove them again afterwards - or keep them as “alpha” as newer, under-development versions on the marketplace.
No, as these entries are created from private accounts, I’d suggest you leave the organization field blank.
Some additional suggestion after seeing the first two listings from @hakan and @TimO, to make the appearance of the listings a little bit aligned (https://marketplace.eclipse.org/content/mysensors-binding and https://marketplace.eclipse.org/content/sensebox):
- Let’s add “Binding” to the label (as we will have other add-on type in future there as well)
- As it is the Eclipse SmartHome marketplace, do not specifically say “for openHAB 2” - it should in general be compatible with any ESH-based solution.
- Let’s try to have logos for the listings, so that the appearance is nicer when browsing them
Thank you for the suggestions @Kai! I’ve fixed these things.
I really like the idea of the marketplace! Is there a way that dependencies could be installed automatically in the future? In case of the MySensors binding “openhab-transport-serial” is needed.
Removing and re-creating whenever a fresh development branch starts would be a hassle I guess. A “disable” button on the marketplace would be nice, so I can hide my entry and restart it quickly whenever I start making changes again.
Where would I create enhancement requests for the marketplace? Eclipse bugzilla perhaps?
Are there licence implications with this?
No, the binding is in any case available under the EPL (assuming you provide a binding from a PR).
Great!
I ve also Binding which could go there.
I love it, opening the Forum and seeing such cool things.
Big kudos to all involved and thanks @Kai !!
BR Mehmet
1 Like
Yes, the plan is to also support Karaf features/archive packaging in future - this would allow to automatically consider all dependencies. The current jar-only approach was what I was able to implement rather quickly for a start and I wanted to have that in place as quickly as possible. From this, we can also learn what else we might expect from the marketplace.
Using apt on Ubuntu with SNAPSHOT builds and I am not seeing the new IoT Marketplace. Looking at cloudbees it appears builds have been unsuccessful since #826. The logs tend to all have the same pattern:
14:52:16.241 | Uploading archive online-repo-2.1.0-SNAPSHOT.zip
15:30:08.779 | Build timed out (after 60 minutes). Marking the build as aborted.
15:30:08.791 | Build was aborted
Not sure if this helps isolate a problem, but trying to be helpful.
Thanks for all the great work on this project. Cheers.
@Kai Kai, is this valid for new PR only? I see that some old historical PR are not in the l-p-l folder (example: KNX). If so, people concerned should close PR and make new ones…
A good PR builder should really save people time on all sorts of hosting issues. I ran into some hosting issues because my submitted bindings failed to download. The only error that showed was “Error reading bundle content.”
Here is some information that may help other people debugging such issues:
- The IoT Marketplace does not host the bundle JARs or JSON files, it only provides links to them. So put these on a reliable host that can handle some traffic.
- The Marketplace content is currently loaded from this catalog. So after approval, it should contain the right URLs.
- Before submitting a binding you can also check if your binding bundle can be properly downloaded/installed via the console by issuing:
bundle:install http://yourhost.org/yourbinding.jar
In the end my hosting issue turned out to be the Cloudflare Browser Integrity Check that disallowed Apache Karaf from downloading files.
PR builds are triggered whenever you push a new commit. If you don’t have anything to push, you can also briefly close and directly re-open an existing PR.
Right, this is what I mentioned here. In the past that was always only a temporary problem; I have no clue why it is failing this time so often in a row…
I have a question.
Say I create a new version of a binding I am working on and it now available on the url specified within the marketplace url.
For beta testers/end users how would upgrading the binding to that latest build work?
thanks,
craig
1 Like
@wborn - did you find a solution to the build problem? My PR (https://github.com/openhab/openhab2-addons/pull/2009) is having the exact same problem with the Feed binding. I can even reproduce the error on a clean clone of the OpenHAB2 Addons repository (none of my code).
It may have to do with that the org.openhab.io.transport.feed bundle provides the com.rometools.rome packages on which the org.openhab.binding.feed bundle depends.
I’m not a tycho dependency resolution expert, but with normal Maven dependencies there should be a dependency on this in the POM of org.openhab.binding.feed however it is not.
I can also imagine such dependency resolution is fine with tycho, but due to implementation changes after a tycho upgrade sometimes fails now.
The reproduction scenario in your PR may help @Kai with solving it.