updated jsonpath to 2.2.0

[kaikreuzer]

Related to #3140 (comment)

Signed-off-by: Kai Kreuzer kai@openhab.org

[maggu2810]

I will wait for Travis and merge if the feature verification succeeded.

[maggu2810]

Does the feature verification work on your machine?

Message: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=esh-transform-jsonpath; type=karaf.feature; version=0.9.0.SNAPSHOT; filter:="(&(osgi.identity=esh-transform-jsonpath)(type=karaf.feature)(version>=0.9.0.SNAPSHOT))" [caused by: Unable to resolve esh-transform-jsonpath/0.9.0.SNAPSHOT: missing requirement [esh-transform-jsonpath/0.9.0.SNAPSHOT] osgi.identity; osgi.identity=org.eclipse.smarthome.transform.jsonpath; type=osgi.bundle; version="[0.9.0.201705111139,0.9.0.201705111139]"; resolution:=mandatory [caused by: Unable to resolve org.eclipse.smarthome.transform.jsonpath/0.9.0.201705111139: missing requirement [org.eclipse.smarthome.transform.jsonpath/0.9.0.201705111139] osgi.wiring.package; filter:="(osgi.wiring.package=com.jayway.jsonpath)" [caused by: Unable to resolve com.jayway.jsonpath.json-path/2.2.0: missing requirement [com.jayway.jsonpath.json-path/2.2.0] osgi.wiring.package; filter:="(osgi.wiring.package=org.apache.tapestry5.json)"]]]

[kaikreuzer]

No it doesn't :-(
Indeed, the 2.2.0 bundle introduced a package-import on org.apache.tapestry5.json :-(
Most other imports are flagged optional, this one isn't...
It has been fixed on master already, unfortunately a month after the 2.2.0 release.

[maggu2810]

Hm, not so good...
Should we revert the bump and wait for a new release?
Should we backport the change and create a new release ourself (WRT to a new CQ)?

[kaikreuzer]

... or shall we create a CQ for 2.1.0 after all, which doesn't have that dependency?

[maggu2810]

... or shall we create a CQ for 2.1.0 after all, which doesn't have that dependency?

I think so.
We should ensure, that the feature verification succeeds using 2.1.0 and then create a CQ.

[sjsf]

diff --git a/features/karaf/esh-ext/src/main/feature/feature.xml b/features/karaf/esh-ext/src/main/feature/feature.xml
index 8bba9b70a..fc309bdbf 100644
--- a/features/karaf/esh-ext/src/main/feature/feature.xml
+++ b/features/karaf/esh-ext/src/main/feature/feature.xml
@@ -85,7 +85,7 @@
   <feature name="esh-transform-jsonpath" description="JSONPath Transformation" version="${project.version}">
     <feature>esh-base</feature>
     <bundle start-level="75">mvn:org.eclipse.smarthome.transform/org.eclipse.smarthome.transform.jsonpath/${project.version}</bundle>
-    <bundle dependency="true">mvn:com.jayway.jsonpath/json-path/2.0.0</bundle>
+    <bundle dependency="true">mvn:com.jayway.jsonpath/json-path/2.1.0</bundle>
     <bundle dependency="true">mvn:net.minidev/asm/1.0.2</bundle>
     <bundle dependency="true">mvn:net.minidev/json-smart/2.1.1</bundle>
   </feature>

looks okay:

[INFO] Eclipse SmartHome Karaf Feature Verification ....... SUCCESS [01:05 min]

=> CQ 13559 created

[kaikreuzer]

CQ has been approved, I updated this PR to use version 2.1.0 now.

[kaikreuzer]

Additionally created #3540 for updating the 3rd party repo.

[maggu2810]

We missed the changes of the targetplatform: https://github.com/eclipse/smarthome/blob/568100a/targetplatform/smarthome.target#L139

[kaikreuzer]

You are right - imho we should change it to 0.0.0, wdyt?
By having removed the 2.0.0 version from the repo, I fear I have also (again) broken the build for older beta releases... Let's see if anybody screams ;-)

[maggu2810]

Hm, it depends how we would like to handle that "older beta releases" at all.
If we start using 0.0.0 an upgrade or a downgrade will affect other betas, too.

We should consider if we would like to keep the old ones as long as possible (so, using versions in the targetplatform and keep 2.0.0, 2.1.0, 2.2.0, and so on) in the repo or if we start using another approach to support old and new versions (allow compilation etc.).

[kaikreuzer]

If we start using 0.0.0 an upgrade or a downgrade will affect other betas, too.

It will only affect them if code is actively compiled against it - and as long as we update to backward compatible versions, it won't have any impact really. If we had 0.0.0 in smarthome.target, an "old beta" would not compile against 2.1.0 instead of 2.0.0, which should be just fine.

[maggu2810]

I am using Karaf features for the product, so I am not affected, but I would expect that a build of a tagged version will result in the same build result regardless of the build time.
If a product consumes all dependencies that is offered by the respective p2 repo a later build of the same beta tag will differ.

[kaikreuzer]

What we provide as build results are (karaf & p2) features. None of these directly reference resources on the p2 site. So if a solution has some (custom) packaging defined that relies on the p2 repo, this is imho nothing that we need to support; what we need to ensure is that the build of the source code works and this is the case.

[kaikreuzer]

Created #3541.

[IOOOTAlan]

Did this change just remove jsonpath-2.0.0 from the third-party repo?
Our ESH-0.9.0b4 builds just broke...

[kaikreuzer]

Let's see if anybody screams ;-)

Ah, that was quick :-)
Ok, so let's put both versions on the repo for now. But definitely a good reason for #3541 (where I am just checking why it breaks the build...)

[kaikreuzer]

Created #3544

[kaikreuzer]

@IOOOTAlan Try again, please!

[IOOOTAlan]

@kaikreuzer 👍
Thank you!