Upgrade Z-Smart Systems library to 1.4.1

[cdjackson]

This brings the following major changes -:

• Improve error handling during Ember network initialisation
• XBee: Handle interrupted/timed out requests when getting channel.
• Improve TelegesisFirmwareUpdateHandler to follow the XModen-CRC protocol
• Move firmware command to dedicated command handler
• Fix EmberFirmwareUpdateHandler to follow the XModem-CRC protocol and also fix retry logic
• Update Ember ncphandler command to support reading statistics counters
• Allow hex addresses in node ID in console commands
• Improve channel selection command for Ember

@kaikreuzer or @wborn I don't think that anything further is now required in the distro as I think you are pulling in dependencies from the feature - right? So merging this will automatically make the updated dependencies available?

If so, please feel free to merge.

Signed-off-by: Chris Jackson [email protected]

[wborn]

I think you are pulling in dependencies from the feature - right?

Yes that was done with openhab/openhab-distro#1158.

So merging this will automatically make the updated dependencies available?

It will probably build fine with Jenkins. But I wonder if these libs also need to be uploaded to the openHAB JFrog Maven repo. 🤔
This was for instance recently an issue with the system info binding libraries (openhab/openhab-addons#11294). If the libraries are embedded into the bundles it should be no issue.

[cdjackson]

Thanks. The libs are not embedded - they need to be pulled in with maven. I assumed this was best rather than embedding the JAR within the bundle.

The libraries are on central - why do they need to be uploaded to an OH repo?

[wborn]

The distro currently only uses the openHAB online repo for downloading online artifacts and not Maven Central. IIRC on Bintray the openHAB repos would also proxy Maven Central artifacts, but there was not enough available storage with the free JFrog plan. It's certainly an annoying issue. 🙁

[cdjackson]

So how best do we proceed so we can get this merged? I'm not super keen to embed the JARs as it removes the flexibility to debug using different libraries. It seems (to me at least) like the best option is for OH to pull directly from central, but I guess that's not a quick option (if at all).

Shall I merge this and then sort out any library updates required in the distro if needed?

[wborn]

the best option is for OH to pull directly from central

If it is not possible to proxy artifacts from Maven Central on the openHAB JFrog repo anytime soon, it might also be an option to add Maven Central release artifacts to the org.ops4j.pax.url.mvn.repositories list. WDYT @kaikreuzer?

Shall I merge this and then sort out any library updates required in the distro if needed?

I would go with that. There was a recent 3.2.0.M3 that people can revert to if they have issues. Another way to workaround these download issues is by using the add-on KAR file.

[kaikreuzer]

Sorry guys, I have been on a business trip this week, so I am only able to respond now.
I have uploaded version 1.4.1 of all jars to our Artifactory, so all should be fine.

Indeed, we haven't yet solved the dependency issue to be automated in some way. Yes, we could add Maven Central to org.ops4j.pax.url.mvn.repositories, but it isn't there on purpose - we wanted to have openHAB independent from any remote repos, so that everything that is required for installation is under our control. If we don't find any suitable other way to handle it, we might reconsider this, though.

[cdjackson]

Hey @kaikreuzer. Thanks for the feedback. I can understand the approach of not relying on other repos where this is someones "random" repo that could disappear without notice, or be unreliable and ultimately cause a bad experience for OH users, but is this really the case with central. I just wonder if the pain/gain ratio makes it worth the hassle of having to support this yourself when dependencies are available in central?

[wborn]

we wanted to have openHAB independent from any remote repos

Without having all the compile/test dependencies of Maven Central in our own repo with a proxy, we won't be able to build openHAB when Central goes down one day.

[cdjackson]

Without having all the compile/test dependencies of Maven Central in our own repo with a proxy, we won't be able to build openHAB when Central goes down one day.

Sure, but how likely is that? Half of the Java world uses central, so openHAB won't be alone. It's obviously up to you guys, but it just seems to me that this unlikely scenario that "one day" central might fail for a few hours, is not worth the hassle it causes and maintaining things could be a lot simpler (IMHO).

[wborn]

Yes the openHAB repo (Bintray) has more availability issues than Maven Central. 😉

If we truly want to stay independent, we should also make sure our build servers don't download anything from Maven Central. So we can spot that we are and stay independent and everything is in our repos. Maybe the openHAB Foundation can help paying for a plan that allows for proxying Maven Central?

[kaikreuzer]

I think it makes a big difference if we speak about the build or the product. For the build: Yes, clearly it is very normal to depend on Maven Central (and it used to be normal to depend on JCenter 🙄) and hence we do this as well. But imho it is very unusual that a product itself also depends on Maven Central - i.e. the binary that we deliver to the users. It should ideally be self-contained and if not, it should download only well-defined packages from our own server. And for security reasons, we should avoid that it is able to download whatever other artifacts that exist in the world...

Maybe the openHAB Foundation can help paying for a plan that allows for proxying Maven Central?

We actually had Artifactory proxying Maven Central, but this does not make much sense. It put a huge load on our instance, causing immense data transfer as all builds also received the artifacts through Artifactory only. Btw, if we'd go for a paid plans, we would end up at roughly 1000$/month, which is way beyond anything reasonable.

[cdjackson]

I think it makes a big difference if we speak about the build or the product.

I agree, but it seems to me that you are doing the job of the build manually - aren't you? You are manually copying the dependencies into your own repository when you should be able to do this as part of the build process when generating the product. That way we should be able to define dependencies in the bindings and not have to manually upload them to the repo?

[kaikreuzer]

In the past we used the KAR file and exploded that as a remote repo - it contains everything that is needed, but nothing more. If we could find a similar mechanism, this would imho be ideal.