Binding Developement Maven trouble

Add-ons Bindings
1

I am working on a resol binding (discussion thread, github repo). When I started I setup the environment and cloned the openhab-core and a fork of openhab2-addons.

Everything went smooth, I could compile and debug from within ecplise and to install a jar on my productive openhab instance (which is running OH 2.2.0) and also publish the jar for others to test, I used mvn clean install and a file target/org.openhab.binding.resol-2.3.0-SNAPSHOT.jar was available.

Now - without being able to tell what exactly I changed - Everything is still smooth in eclipse, but the mvn-compiled jar seems to be be built with recent, incompatible changes from openhab-core (rename of static member scheduler in AbstractDiscoveryService), as I get at runtime on an OH2.2.0 instance the following beautiful exception:

… Caused by: java.lang.IncompatibleClassChangeError: Expected non-static field org.openhab.binding.resol.internal.discovery.ResolVBusBridgeDiscovery.scheduler
at org.openhab.binding.resol.internal.discovery.ResolVBusBridgeDiscovery.startScan(ResolVBusBridgeDiscovery.java:43) ~[?:?]
at org.eclipse.smarthome.config.discovery.AbstractDiscoveryService.startScan(AbstractDiscoveryService.java:222) ~[?:?]
at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScan(DiscoveryServiceRegistryImpl.java:409) ~[?:?]

any idea what I am doing wrong? Or how I can force the mvn build to compile against 2.2.0 instead of the snapshot? Maybe @Kai?

3

I’d assume you’d need to change your pom to reference parent pom version 2.2.0 instead of 2.3.0-SNAPSHOT.
By default, all new developed bindings are only compatible with the latest code base, but not with older releases.

4

Thanks for the fast response. I tried already to change those version numbers and did not succeed yesterday. Now during writing down what I have and think is reasonable it works. I document here what I did to build my the binding against the last stable openhab-core, maybe it is helpful for someone else:

openhab-core/pom.xml with version 2.2.0, as I did git checkout 2.2.0 there - this seems to be the code used during my compilation in eclipse, but not considered for a mvn clean install build.

in openhab2-addons/pom.xml I modified the version numbers for the parents to 2.2.0

<parent>
    <groupId>org.openhab</groupId>
    <artifactId>pom-tycho</artifactId>
    <version>2.2.0</version>
    <relativePath/>
</parent>
[...]
<properties>
    <ohc.version>2.2.0</ohc.version>
</properties>
[...]
<version>2.3.0-SNAPSHOT</version>

in openhab2-addons/addons/binding/pom.xml I adjusted the parent version to 2.2.0

<parent>
   <groupId>org.openhab.addons</groupId>
   <artifactId>pom</artifactId>
   <version>2.2.0</version>
</parent>

in my bindings pom I changed nothing and therefore have 2.3.0-SNAPSHOT for now.

Somehow it doesn’t feel completely correct as the binding is now targeting a 2.2.0 OH core while having a version number 2.3.0-SNAPSHOT, but for now it works at least.

Please correct me if my understanding is wrong in some place.

5

Hi @ramack,

I’ve installed the latest milestone version of openHAB, M6 and I facing the same issue:
Caused by: org.glassfish.jersey.server.ContainerException: java.lang.IncompatibleClassChangeError: Expected static field org.openhab.binding.resol.internal.discovery.ResolVBusBridgeDiscovery.scheduler

This error is produced when I request a SCAN for discovery resol Things.
Could you let me know how to fixe this issue?

6

Hi @Yann
to be honest I have no glue. I did not followup the changes in the core, but also would expect, that they are backward compatible to existing bindings, aren’t they? Did you install the compiled version from the marketplace? What they changed in the core with the scheduler field is hopefully explained somewhere…
As @kai explained this change should be source compatible, so maybe we would just need to recompile the binding. Interesting is, that for 2.3 it automatically worked.

7

Hi @Kai,
Could you help on this issue between the M6 milestones and the binding?
Any advise or new binding version … any help would be appreciate :wink:
Regards

8

All that is required is to have a compiled version against 2.4.0-SNAPSHOT.
The easiest solution would be to make this binding a part of the official distro, i.e. create a PR against the openhab2-addons repo. Already by creating the PR, our Jenkins will automatically build and publish an up-to-date binary version of it.
@ramack Any special reason why you haven’t considered creating a PR yet?

9

@Kai no, there is not really a special reason. Just the fact that the code is not really clean with some open todos, such that I don’t think it is ready for a review from your side. For example Zi also remember some stuff that was previously done in code (and is currently in this binding) that nowadays should be in XML declaration… And the used library is integrated by copy-pasted files which has to be replaced by integration of a jar but I miss the maven background to do so.

1 Like
10

Thank you for this feedback @ramack, I understand and I don’t have maven background as well to help on this.
@Kai: any chance to ask some else to help on this ? Except the todos … sounds more like a refactoring. Could you help on this or assign someone from the community?
Thank you for your follow-up :slight_smile:

11

Nope, I cannot “assign someone”. You can ask the community here yourself, whether anyone wants to help on it.

12

@yphyph01 Maybe the effort left to create a PR against the main repo is not that big and it should definitely be worth the effort. I plan to push some more effort into this again, but theses days are quite busy for me, so it will take some time. In my fork of opnehab2-addons I have also created some tickets to track what is on the “todo” list. If you are able to help, that would be great - I think there is no rocket science in that binding, so time and motivation are the only reasons not to contribute :slight_smile:

13

@ramack,

OK Ramack, I can spend some time on this but, I’ll need some guidance.
First of all, I’ll need an up-to-date dev environment. Could you share your envrionnement. Which tools are you using? Eclispe? Could you help to set it up?
I’ll need also an acces to your GIT. Could you provide it?

14

@yphyph01 great.
For getting access you can fork my repo into your github account. Then you push all changes to this and create a pull request against my repo, or - if you want to take the lead even directly to the origin openhab/openhab2-addons.

For the dev-env I am also quite novice, so please check the official docs and come back with questions. I remember it was a bit tricky when I did it, but even I managed to get it working :slight_smile: And yes, I use eclipse.

15

@ramack
OK, I guess I’ve got this installed :slight_smile: Repo forked :slight_smile:
At this stage, I need to check the “output”. How to test it?

And what’s next. What are the steps to put it in the PR ?

16

That’s good news. Thanks for helping out here!
Maybe the first step would be to merge the changes from upstream into the repository.

Then I think the next most things are #17 - DS annotations instead of XML and #6 - replace the source code copy-past of the resol-vbus-java library by the jar

For the last I also have no clue how it shall be done, but I guess we will find another binding using a jar as library or we can ask @kai for a pointer, maybe there is some docs available.

Beside those and some left cleanup the only important thing is that there seem to be an issue with the typing. At least I have seen on my system, that sometimes the °C is shown for the channels and sometimes there is no unit but a very big amount of decimals behind the comma. It is not really consistent and I miss the idea how to debug that behavior.

The other open tickets are mainly feature requests, which are nice to have, but not mandatory for creating a PR against the official repository. Until then I propose to work in my github fork, with PRs from yours into mine, but if you want to take the lead I am also perfectly fine to finally create the official PR from your fork. - whatever you think is best. The target is to have the best code that we can create together in the official openhab repo, the way to this is not predetermined :slight_smile:

Also whenever you have questions don’t hesitate to ask me here or by mail.