kstegemoller
commented
3 years ago To solidify requirements for this removal script, I am using the find-repeated-jars.sh documented in https://github.com/opengeospatial/cite-private/issues/212 suggested by @dstenger. I got these results with my test... I would expect us to keep the newest version by number. Other expectations? See my questions to the right.
=== Current jars ===|=== jars to be Removed; jars to be kept marked with '<' ===
ets-gml311-3.1.jar <
ets-gml32-0.1.jar ets-gml32-0.1.jar ### Do we need to keep different versions of ets?
ets-gml32-1.21.jar ets-gml32-1.21.jar
ets-gml32-1.25.jar ets-gml32-1.25.jar
ets-gml32-3.2.jar <
fii-boo-zoom-fast-4.7.0.jar fii-boo-zoom-fast-4.7.0.jar
fii-boo-zoom-fast-4.7.2.jar fii-boo-zoom-fast-4.7.2.jar
fii-boo-zoom-fast-4.7.jar < ### the 4.7.2 version should be kept. Do we need to worry about this use case?
foo-bar-baz-2.6.2.jar foo-bar-baz-2.6.2.jar
foo-bar-baz-2.7.2.jar foo-bar-baz-2.7.2.jar
foo-bar-baz-2.7.9.jar <
geotk-utility-3.21.jar <
geotk-utility-pending-3.21.jar geotk-utility-pending-3.21.jar ### Should both pending and "non pending" versions be kept?
json-20080701.jar json-20080701.jar
json-20090211.jar <
liba-2.1.jar liba-2.1.jar
liba-2.2.jar <
lib-client-1.17.1.jar lib-client-1.17.1.jar
lib-client-1.18.1.jar <
lib-server-3.16.jar lib-server-3.16.jar
lib-server-3.19.jar <
teamengine-spi-5.3.jar teamengine-spi-5.3.jar
teamengine-spi-ctl-5.3.jar < ### BUG This appears to be a different jar should and should keep both.
wii-gee-2019-11-11.jar < ### BUG Does not work -- will not fix?
wii-gee-2020-09-00.jar < ### BUG Does not work -- will not fix?
zii-bee-20201110.jar zii-bee-20201110.jar
zii-bee-20210990.jar <
ghobona
dstenger
E.g. create script to remove duplicated dependencies automatically.
Description of the problem: Currently, in many cases, there are the same dependencies in different versions in the classpath (lib folder of TEAM Engine webapp). This problem is caused by different test suites having the same dependency but not in the same version. Due to that fact, a random version of those multiple dependencies is chosen leading to system related test failures in different test suites (e.g. ets-wfs20;
java.lang.NoSuchMethodError: org.opengis.cite.validation.SchematronValidator.validate(Ljavax/xml/transform/Source;Z)Ljavax/xml/transform/Result;). Because of that, we are deleting older versions of multiple dependencies manually so that just the newest version stays in the classpath (of course, this is not a good workflow and more a workaround; a general solution is needed here). When a Docker Container is started this task of deleting multiple dependencies should be executed automatically (e.g. via script).