search

camunda / camunda-bpm-platform

Flexible framework for workflow and decision automation with BPMN and DMN. Integration with Quarkus, Spring, Spring Boot, CDI.
https://camunda.com/
Apache License 2.0
4.11k stars 1.55k forks source link

Update json-path to the latest version #3275

Closed ThorbenLindhauer closed 1 year ago

ThorbenLindhauer commented 1 year ago

Acceptance Criteria (Required on creation)

Hints

Links

Breakdown

Dev2QA handover

ThorbenLindhauer commented 1 year ago

PRs are prepared. Will wait to give them into review until current release activities are finished.

ThorbenLindhauer commented 1 year ago

JSON path dependencies before:

[INFO] +- com.jayway.jsonpath:json-path:jar:2.6.0:compile [INFO] | - net.minidev:json-smart:jar:2.4.7:compile [INFO] | - net.minidev:accessors-smart:jar:2.4.7:compile

Dependencies after:

[INFO] +- com.jayway.jsonpath:json-path:jar:2.8.0:compile [INFO] | - net.minidev:json-smart:jar:2.4.10:runtime [INFO] | - net.minidev:accessors-smart:jar:2.4.9:runtime

All three dependencies remain Apache-licensed.

ThorbenLindhauer commented 1 year ago

I'll create the other PRs once the Spin changes are merged and released.

ThorbenLindhauer commented 1 year ago

Note that in the RPA bridge we explicitly need to override the json-path and json-smart versions, because the Spring Boot BOM manages them as well and uses lower versions (even on Spring Boot 2.7.10, the json-path version is 2.7.0, json-smart is 2.4.10 (this is fine)).

We do not have the same problem in Run, because we use dataformat-all there. We have a slight problem in the Spring Boot starter itself: During compile time, the Spring-Boot-managed versions take precedence too. However for users, when consuming the starter with an additional Spin dependency (otherwise Spin is not included, because the starter declares it as optional), the json-path/smart versions are correct. Unless the user also declares the Spring Boot BOM in addition, but then it's their task to override the json-path/smart versions.

This leaves us with problem that we use older dependencies during compiling and unit testing of the Spring Boot starter modules (integration tests are fine, because they consume the starter like described in the last paragraph). I think this is an acceptable risk and weighs less than the risk of overriding the versions explicitly and later forgetting to undo or update it (with new Spin versions; with new Spring Boot versions).

ThorbenLindhauer commented 1 year ago

I have added runtime as a scope to the dependency that we include in the Wildfly modules, because json-smart and accessors-smart are now runtime dependencies of json-path. Once the CI succeeds, I will perform a diff of the modules included in the Wildfly distros to ensure nothing else got added by accident.

ThorbenLindhauer commented 1 year ago

Wildfly artifacts for master and 7.17 look good. There are no unexpected differences.

I noticed though that due to the change of dependency scope, the minidev dependencies are no longer included in the third-party-dependency files and would therefore not appear in the license book.

ThorbenLindhauer commented 1 year ago

Need to make sure that the minidev dependencies are included in the following dependency lists (based on 7.19.0 license book):

camunda-ibm-websphere-ear-7.20.0-SNAPSHOT-third-party-bom.txt,
camunda-webapp-ee-wls-standalone-7.20.0-SNAPSHOT-third-party-bom.txt,
camunda-oracle-weblogic-ear-7.20.0-SNAPSHOT-third-party-bom.txt,
camunda-webapp-ee-tomcat-standalone-7.20.0-SNAPSHOT-third-party-bom.txt,
camunda-wildfly-modules-7.20.0-SNAPSHOT-third-party-bom.txt,
camunda-webapp-ee-jboss-standalone-7.20.0-SNAPSHOT-third-party-bom.txt,
camunda-webapp-jboss-standalone-7.20.0-SNAPSHOT-third-party-bom.txt,
camunda-webapp-ee-was9-standalone-7.20.0-SNAPSHOT-third-party-bom.txt,
camunda-webapp-tomcat-standalone-7.20.0-SNAPSHOT-third-party-bom.txt,
camunda-wildfly26-modules-7.20.0-SNAPSHOT-third-party-bom.txt,
camunda-spin-dataformat-all-1.19.0-third-party-bom.txt
ThorbenLindhauer commented 1 year ago

@tmetzke can you please review the Spin PRs? After that I will build another set of patches and then continue with the platform PRs.

tmetzke commented 1 year ago

@ThorbenLindhauer, do we need to adjust this on Spin's main branch as well (currently only in 1.19, 1.18, and 1.14)?

ThorbenLindhauer commented 1 year ago

Definitely. Will do.

edit: here it is: https://github.com/camunda/camunda-spin/pull/195

ThorbenLindhauer commented 1 year ago

Overview of remaining PRs:

CE platform (Spin update + license book):

EE platform (license book):

RPA Bridge: