Jenkins build problems

Hm, AFAIK it is part of “aether-api”

Yes, you are right. I probably got a bit confused by the two different libraries with similar names from Sonatype and

Can you create a Job that executes

(cd openhab-core/features/openhab-core; mvn -X org.apache.karaf.tooling:karaf-maven-plugin:4.0.8:features-generate-descriptor)

So, only the stuff that is really necessary for this goal is in the classpath?

You could then change 4.0.8 to the most recent plugin version 4.1.1 for this goal only.

Yes, I will do that.

Can you create a Job that executes […] only?

This will work as running the full openhab-core project also succeeds:
The problem only starts once it is put together into a reactor with the other repos through openhab-bundles.

Is there any fix where you think it will solve our problem? The “this goal only” part is important - we must make sure that the distro won’t suddenly use 4.1.x.

Just a quick update: I created an exact copy of the build job (okay, admittedly without the publishing and email post-build-steps…) and reducing the complexity stepwise:

The full build as we know it (using karaf-maven-plugin 4.0.8):

-f ./pom.xml -U clean install -DskipChecks=true

Only doing the karaf feature generation (using karaf-maven-plugin 4.1.1) but still for the whole project:

-f ./pom.xml -U clean org.apache.karaf.tooling:karaf-maven-plugin:4.1.1:features-generate-descriptor -DskipChecks=true -e -X

So the karaf version does not seem to matter. Also the

Only running the karaf feature generation (using karaf-maven-plugin 4.1.1) only for one subproject - interestingly it succeeds:

-f ./openhab-core/features/openhab-core/pom.xml -U clean org.apache.karaf.tooling:karaf-maven-plugin:4.1.1:features-generate-descriptor -DskipChecks=true -X

Ok, I have some news! The Cloudbees support continued to look into it (I am amazed that they are so dedicated to even support non-paying open source projects so eagerly :thumbsup: ) and here’s what they found:

we discovered that the problem is related to the Deploy artifacts to Artifactory post-build action. Removing this post build action everything seems to work fine.

Why this is happening now and not before is because of the upgrade of the Maven plugin to the latest version on March 31 (this was a massive upgrade in all DAC instance because of a security issue).

We tried to fix the problem upgrading the Artifactory plugin but it didn’t help. I’m still working on it in order to find a solution.

So after all, the problem started through some change on the Cloudbees infrastructure - let’s hope that they can find a solution for it; otherwise I might change the builds to deploy the artifacts in some other way. I’ll keep you posted.


Short update: Cloudbees will look into fixing the Artifactory plugin, but this can take many weeks as it isn’t trivial. I’ll therefore go for a workaround and see if I either use a local Maven repo on Cloudbees for passing the artifacts from the bundle build to the distro build or to do a “mvn deploy” to Artifactory without using the plugin. As I am on holiday this week, my time is pretty limited - but I’ll make sure to resolve the issue over Easter, so that we have up-to-date snapshot builds again in a few days from now. Will keep you posted.


Ok, first success: I have removed the use of the Artifactory plugin in the bundles and the distro build and instead the artifacts are deployed by the normal Maven deploy mechanism. Both builds are green again, which means that you can again get the current snapshots from

One last thing I need to do is to also populate the online repo from the build. Currently, this still holds old snapshots, so that you will not get the latest bindings, if you do not also download/install the addons package for offline usage. Will work on this next (hopefully tonight).


Hi all,

I just updated my OH2 to the latest snapshot.
But now I get NPEs in zwave binding and the complete zwave control is not working anymore. So I guess there is an incompatibility from latest OH2 snapshot to older binding snapshots?

Just to inform you all.

CHeers MArkus

What are the NPEs? There haven’t been many changes to the master branch of the zwave binding for a month or so - just 3 commits and I don’t think they should change much, but it would be interesting to see what the NPE is.

Hi CHris,

e.g. this here during idle operations

2017-04-16 16:02:34.277 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 10: Application Command Request (INITIALIZING:PROTOINFO)
2017-04-16 16:02:34.278 [ERROR] [ve.internal.protocol.ZWaveController] - Exception during ZWave thread: Input 2. {}
	at org.openhab.binding.zwave.internal.protocol.ZWaveNode.setNodeState([196:org.openhab.binding.zwave:]
	at org.openhab.binding.zwave.internal.protocol.serialmessage.ApplicationCommandMessageClass.handleRequest([196:org.openhab.binding.zwave:]
	at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingRequestMessage([196:org.openhab.binding.zwave:]
	at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingMessage([196:org.openhab.binding.zwave:]
	at org.openhab.binding.zwave.internal.protocol.ZWaveController.access$7([196:org.openhab.binding.zwave:]
	at org.openhab.binding.zwave.internal.protocol.ZWaveController$[196:org.openhab.binding.zwave:]

Or this one if I try to switch power on/off (node 10 is a power plug)

2017-04-16 16:28:49.976 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 10: ProtocolInfo
2017-04-16 16:28:49.977 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 10: Listening = true
2017-04-16 16:28:49.979 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 10: Routing = true
2017-04-16 16:28:49.980 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 10: Beaming = true
2017-04-16 16:28:49.982 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 10: Version = 4
2017-04-16 16:28:49.984 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 10: FLIRS = false
2017-04-16 16:28:49.985 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 10: Security = false
2017-04-16 16:28:49.987 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 10: Max Baud = 40000
2017-04-16 16:28:49.988 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 10: Basic = Routing Slave
2017-04-16 16:28:49.989 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 10: Generic = Binary Switch
2017-04-16 16:28:49.990 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 10: Specific = Binary Power Switch
2017-04-16 16:28:49.992 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 10: Creating new instance of command class NO_OPERATION
2017-04-16 16:28:49.993 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 10: Command class NO_OPERATION, endpoint null created
2017-04-16 16:28:49.995 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 10: Version = 1, version set. Enabling extra functionality.
2017-04-16 16:28:49.997 [ERROR] [ve.internal.protocol.ZWaveController] - Exception during ZWave thread: Input 2. {}
	at org.openhab.binding.zwave.internal.protocol.ZWaveNode.addCommandClass([196:org.openhab.binding.zwave:]
	at org.openhab.binding.zwave.internal.protocol.serialmessage.IdentifyNodeMessageClass.handleResponse([196:org.openhab.binding.zwave:]
	at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingResponseMessage([196:org.openhab.binding.zwave:]
	at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingMessage([196:org.openhab.binding.zwave:]
	at org.openhab.binding.zwave.internal.protocol.ZWaveController.access$7([196:org.openhab.binding.zwave:]
	at org.openhab.binding.zwave.internal.protocol.ZWaveController$[196:org.openhab.binding.zwave:]
2017-04-16 16:28:54.910 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 255: Too many retries. Discarding message: Message: class=IdentifyNode[0x41], type=Request[0x00], priority=High, dest=255, callback=0, payload=0A 
2017-04-16 16:29:59.154 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Command received zwave:device:a62f5073:node10:switch_binary --> ON
2017-04-16 16:29:59.156 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occured while calling handler: java.lang.NullPointerException
java.util.concurrent.ExecutionException: java.lang.NullPointerException
	at org.eclipse.smarthome.core.common.SafeMethodCaller.executeDirectly([99:org.eclipse.smarthome.core:]
	at org.eclipse.smarthome.core.common.SafeMethodCaller.callAsynchronous([99:org.eclipse.smarthome.core:]
	at org.eclipse.smarthome.core.thing.internal.ThingManager.receiveCommand([106:org.eclipse.smarthome.core.thing:]
	at org.eclipse.smarthome.core.common.SafeMethodCaller$[99:org.eclipse.smarthome.core:]
	at java.util.concurrent.ThreadPoolExecutor.runWorker([:1.8.0_121]
	at java.util.concurrent.ThreadPoolExecutor$[:1.8.0_121]
Caused by: java.lang.NullPointerException
	at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveBinarySwitchCommandClass.setValueMessage([196:org.openhab.binding.zwave:]
	at org.openhab.binding.zwave.internal.converter.ZWaveBinarySwitchConverter.receiveCommand([196:org.openhab.binding.zwave:]
	at org.openhab.binding.zwave.handler.ZWaveThingHandler.handleCommand([196:org.openhab.binding.zwave:]
	at org.eclipse.smarthome.core.thing.internal.ThingManager$[106:org.eclipse.smarthome.core.thing:]
	at org.eclipse.smarthome.core.thing.internal.ThingManager$[106:org.eclipse.smarthome.core.thing:]
	at org.eclipse.smarthome.core.common.SafeMethodCaller.executeDirectly([99:org.eclipse.smarthome.core:]
	... 12 more

Done! The online repo is now also filled with the latest snapshot builds, so all should be fine again!

@mbuchberger1967 Any issues that you might find from now should be considered as bugs, so please open a dedicated topic or issue for them.

1 Like


I just did an apt-get update / upgrade but no changes arrived ( I use apt-get on snapshot repository)
I’d have expected to get update on bindings… can u explain me why there are no changes in apt-get?

DO I need to use manual installation to get the latest snapshots on bindings?

Sorry, maybe a stupid question but I’m confused a little bit now.


If your are on unstable builds, you should have build #884. I have. :slight_smile:

where shall I create an issue? here in the forum or is there another system in place for bug tracking?

I guess because @rtvb got the newest build you are just doing something wrong …

Double check if you did all required steps and if you are really on snapshot builds:

Edit: ahhh, you just forgot to report you’ve solved it: :grinning:

I’m having a similar issue with the zwave binding (both 2.1.0 and the in work security version) after updating to the latest snapshot (2.1.0-SNAPSHOT Build 884). The error message below consistently occurs at start up and goes away after uninstalling the zwave binding.

2017-04-16 18:37:22.697 [ERROR] [org.openhab.binding.zwave           ] - FrameworkEvent ERROR - org.openhab.binding.zwave
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zwave [230]
  Unresolved requirement: Import-Package:

	at org.eclipse.osgi.container.Module.start([org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel([org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel([org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel([org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent([org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent([org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent([org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.framework.eventmgr.EventManager$[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]

For post update troubleshooting, I also ran sudo apt-get install openhab2-addons with no change in results.

All else seems to work okay after the update.

Thank you, this seems to have corrected the error.

I thought this was odd, however, because I haven’t been doing anything with my zwave binding (I was using the available version from the Paper UI) and this was new behavior since Kai was able to make the latest snap shot available again. I did a typical snapshot update via apt-get which is what triggered the error.

Question little off topic but where can I find road map of OpenHab?
I’m almost happy user of OpenHabian and I wonder when I see e.g 2.1. I waiting for this version because as I know it fix this bug Strange behaviour of Fibaro Flood Sensor with Razberry and OpenHabian .

I know I can use snapshot but I’m affraid using snapshot because later migration problems…but maybe I’m wrong?

Michał Szymański