Workaround for transformation from epsg:3857 with wrong results

[stempler]

We were experimenting a bit with transformations from EPSG:3857 that are producing wrong results, specifically to EPSG:31468 / EPSG:4314 where data would be moved by ~20 km.

Example:

Debugging the transformation we could not really pinpoint where the things go wrong.

So for now we here implemented a workaround to get correct results, by having WGS 84 as an intermediate step in the transformation.
This is definitely not pretty and an actual fix would be preferable, but I was wondering if something like this workaround would in principle be something that you would consider to be added to the codebase. Thanks!

[copierrj]

What problem is being solved exactly by adding an additional test dependency (com.sun.xml.ws:jaxws-rt)?

[stempler]

What problem is being solved exactly by adding an additional test dependency (com.sun.xml.ws:jaxws-rt)?

@copierrj The error is a NoClassDefFoundError for org.codehaus.stax2.XMLInputFactory2. The error may also surface as CRS failing to load (because the CRSManager fails to initialize due to the NoClassDefFoundError).
I used the com.sun.xml.ws:jaxws-rt dependency because I saw that stax2 was not used directly as dependency so far, but this. So instead of defining a new one I reused this one.

This is unrelated to the CRS transformation issue, I just needed it to run the tests. As mentioned in the related commit message tests would fail for me otherwise:

• with Maven and Java 17 (did not test with Java 11, maybe related to the message OpenJDK 64-Bit Server VM warning: Ignoring option --illegal-access=permit; support was removed in 17.0)
• in IntelliJ with Java 11

[stempler]

This is unrelated to the CRS transformation issue, I just needed it to run the tests. As mentioned in the related commit message tests would fail for me otherwise:

• with Maven and Java 17 (did not test with Java 11, maybe related to the message OpenJDK 64-Bit Server VM warning: Ignoring option --illegal-access=permit; support was removed in 17.0)
• in IntelliJ with Java 11

Also observed this with Java 11 (OpenJDK) and Maven 3.9:

$ mvn -version
Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
Maven home: /home/simon/apps/apache-maven-3.9.0
Java version: 11.0.20.1, vendor: Ubuntu, runtime: /usr/lib/jvm/java-11-openjdk-amd64
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.15.0-83-generic", arch: "amd64", family: "unix"

So no idea how the tests run on other systems, but for me a large amount of tests fail without the additional dependencies.

[stempler]

Any feedback on the actual topic of the PR?
As the tests seem to run on your infrastructure without the NoClassDefFoundErrors, I can drop the commit extending the test dependencies.

[copierrj]

Java 17 is not supported yet by deegree, but any Java 11 JDK should be sufficient to build deegree (and run the tests) without any additional dependencies needed.

If you remove the commit introducing the new dependency and Jenkins subsequently is able to successfully build and test it we're ready to merge your PR.

[stempler]

Thanks! I updated the PR.

[copierrj]

FYI: we're currently experiencing problems on our build server. We'll get back to this PR when these problems are resolved.