critical dependency update + citrusframework/citrus-simulator fix

[bbortt]

detected incompatibility in citrus-mail dependency, whenever citrus-openapi is also available on the classpath.
with this commits, citrusframework/citrus-simulator#315 is finally mergeable.

additionally fixes reported https://github.com/advisories/GHSA-fghv-69vj-qj49.
original MR: #1399.

[bbortt]

hm. pipeline on 81a76ac failed with same error as https://github.com/citrusframework/citrus/actions/runs/17472064447/job/49622669759?pr=1399#step:6:11387. didn't see that beforehand.

[christophd]

👍

[bbortt]

@christophd I've moved the version declarations and improved the commit messages. dependency tree is as following (citrus-simulator-sample-mail):

[INFO] |  \- org.citrusframework:citrus-openapi:jar:4.9.0-SNAPSHOT:compile
[INFO] |     +- io.apicurio:apicurio-data-models:jar:1.1.33:compile
[INFO] |     +- com.atlassian.oai:swagger-request-validator-core:jar:2.46.0:compile
[INFO] |     |  +- com.github.java-json-tools:json-schema-validator:jar:2.2.14:compile
[INFO] |     |  |  +- com.github.java-json-tools:jackson-coreutils-equivalence:jar:1.0:compile
[INFO] |     |  |  +- com.github.java-json-tools:json-schema-core:jar:1.2.14:compile
[INFO] |     |  |  |  +- com.github.java-json-tools:uri-template:jar:0.10:compile
[INFO] |     |  |  |  \- org.mozilla:rhino:jar:1.7.7.2:compile
[INFO] |     |  |  +- joda-time:joda-time:jar:2.10.5:compile
[INFO] |     |  |  +- com.googlecode.libphonenumber:libphonenumber:jar:8.11.1:compile
[INFO] |     |  |  \- net.sf.jopt-simple:jopt-simple:jar:5.0.4:compile
[INFO] |     |  +- com.google.guava:guava:jar:33.5.0-jre:compile
[INFO] |     |  |  +- com.google.guava:failureaccess:jar:1.0.3:compile
[INFO] |     |  |  +- com.google.guava:listenablefuture:jar:9999.0-empty-to-avoid-conflict-with-guava:compile
[INFO] |     |  |  +- org.jspecify:jspecify:jar:1.0.0:compile
[INFO] |     |  |  +- com.google.errorprone:error_prone_annotations:jar:2.41.0:compile
[INFO] |     |  |  \- com.google.j2objc:j2objc-annotations:jar:3.1:compile
[INFO] |     |  \- com.google.code.findbugs:jsr305:jar:3.0.2:compile
[INFO] |     +- javax.mail:javax.mail-api:jar:1.6.2:compile
[INFO] |     \- com.fasterxml.jackson.datatype:jackson-datatype-jsr310:jar:2.19.2:compile
[INFO] +- org.citrusframework:citrus-mail:jar:4.9.0-SNAPSHOT:compile
[INFO] |  +- org.springframework:spring-core:jar:6.2.10:compile
[INFO] |  |  \- org.springframework:spring-jcl:jar:6.2.10:compile
[INFO] |  +- org.springframework:spring-context-support:jar:6.2.10:compile
[INFO] |  +- com.fasterxml.jackson.core:jackson-core:jar:2.19.2:compile
[INFO] |  +- com.fasterxml.jackson.core:jackson-databind:jar:2.19.2:compile
[INFO] |  |  \- com.fasterxml.jackson.core:jackson-annotations:jar:2.19.2:compile
[INFO] |  +- jakarta.xml.bind:jakarta.xml.bind-api:jar:4.0.2:compile
[INFO] |  +- org.glassfish.jaxb:jaxb-runtime:jar:4.0.5:compile
[INFO] |  |  \- org.glassfish.jaxb:jaxb-core:jar:4.0.5:compile
[INFO] |  |     +- org.glassfish.jaxb:txw2:jar:4.0.5:compile
[INFO] |  |     \- com.sun.istack:istack-commons-runtime:jar:4.1.2:compile
[INFO] |  +- com.icegreen:greenmail:jar:2.1.5:compile
[INFO] |  |  +- org.eclipse.angus:jakarta.mail:jar:2.0.4:compile
[INFO] |  |  \- junit:junit:jar:4.13.2:compile
[INFO] |  +- jakarta.activation:jakarta.activation-api:jar:2.1.3:compile
[INFO] |  +- org.eclipse.angus:angus-activation:jar:2.0.2:compile
[INFO] |  +- jakarta.mail:jakarta.mail-api:jar:2.1.3:compile
[INFO] |  \- org.eclipse.angus:angus-mail:jar:2.0.4:compile

[christophd]

One more thing we could try is to add this dependency and exclude the mail-api in the old version:

<dependency>
    <groupId>com.github.java-json-tools</groupId>
    <artifactId>json-schema-validator</artifactId>
    <version>2.2.14</version>
    <exclusions>
          <exclusion>
            <groupId>com.sun.mail</groupId>
            <artifactId>mailapi</artifactId>
          </exclusion>
    </exclusions>
</dependency>

[bbortt]

@christophd my thoughts on this: I am not sure if that is worth the "risk". I think it's smaller if only the targeted dependency is being modified. from a hierarchical point of view...

if we modify only the mailapi dependency, json-schema-validator is compatible in all cases:

• swagger request validator 🟢
  • json schema validator 🟢
    • mailapi 🔴

if we modify the json-schema-validator, it might occur that this is no longer compatible with the swagger-request-validator-core:

• swagger request validator
  • json schema validator 🔴

it's probably a small risk, but it exists. I wouldn't modify it. any thoughts on that?

[christophd]

I see your point with potential risk.

On the other hand including the mailapi in the transitive dependencies may cause other side effects in users projects that are not compatible with old mailapi. Each user of Citrus would need to add the mailapi exclusion on the citrus-openapi dependency then in their Maven pom.

Because of this I'd prefer to exclude it so the Citrus transitive dependency tree is clean and if needed users would have to add the mailapi again back into their Maven pom as a dependency. WDYT?

[christophd]

I'd like to avoid brining in the old mailapi transitive dependency with Citrus as it looks like Citrus has done a bad job handling its dependencies. But the truth is json-schema-validator is the reason but no one will realize that from the very beginning and the claim is on Citrus.

[bbortt]

we already have the new mailapi in citrus-mail, transitively. citrus-openapi brought in the old one, also transitively. if we declare a version in pom.xml, we now explicitly force this version.

we could just remove it from the transitive dependencies of citrus-openapi (as is). and use the javax.mail-api just in citrus-openapi (as is). rest is irrelevant.

tldr; I will remove this version force.

edit: I've tested it and it works.

[bbortt]

if ok for you I would squash and merge @christophd

[christophd]

Ok, many thanks!

[bbortt]

well thank you for the brainstorming/inputs. it really helped!