Use custom class loaders to load Languagetool dependencies

[Auriga2]

Prerequisites

• Reviewed the checklist

• Reviewed feedback from the "Sonar Cloud" bot. Note that you have to wait
  for the "CI / Unit Tests") to complete first. Failed Unit tests can be
  debugged by adding the label "verbose logging" to the GitHub PR.

Description of the Change

Custom class loaders are now used to load Languagetool dependencies, to avoid indriya version conflicts.

languagetool requires indriya v1.3 or earlier while systems-common used by gt-opengis is not compatible with 1.3 and requires a later version. (v2.0.2 or latest v2.2) This caused #2054

All other approaches I've tried, like ivy configs, Maven Shade Plugin and Relocation, only works for build-time conflicts. In our scenario we need to isolate 2 versions of the same library at runtime. Using a Custom ClassLoader seems to be the only possibility.

I used ivy configs to isolate the languagetool libs into a separate folder, rather than listing all the transient dependencies of languagetool in the code. The latter could cause version conflicts, as Ivy might resolve to different versions than those we have hard-coded. On the other hand ivy configs duplicates the common transient libraries.

I am loading only the Languagetool dependencies separately, keeping the rest of the constellation intact, to avoid too much complications, and when the Languagetool developers fix their issue we can easily revert the changes. (Usually both versions of the dependency is loaded using custom class loaders)

Know issues:
Undo after Ignore all doesn't work (Pre-existed) [Logged #2295 ]

To Do:
Find a way to reuse the common transient libraries.

Alternate Designs

• Fix the bug in org.languagetool
• Use a different spell check library

Why Should This Be In Core?

Enables spell checking in enabled text fields

Benefits

Possible Drawbacks

Complex coding

Verification Process

• Spell checking works (in Data access view)
• Schema view loads without any exception
• Export to GeoPackage and Export to ShapeFile works

Applicable Issues

#870

[sonarqubecloud]

Quality Gate failed

Failed conditions
11.9% Coverage on New Code (required ≥ 80%)
C Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[Auriga2]

To reuse the common transient libraries I let ivy resolve all dependencies in the same location, which avoids duplication. Then in the code I am keeping a list of the jars used by Languagetool in a text file and load those jars from the common location, ignoring the version numbers.

The conflicting library Indriya is resolved into a separate folder languagetoolconf. Indiya 1.3's transient dependency uom-lib-common-1.1.jar was also coupled, that it didn't work with the version that Ivy downloaded for constellation. Hence it's also separately loaded from the languagetoolconf folder.

[Delphinus8821]

Its working well, just a few minor changes

[OrionsGuardian]

There seems to be a configuration issue when trying to build constellation-adapters with the spellcheck version of constellation as the base.

:: resolving dependencies :: au.gov.asd.tac#third-party-dependencies;working@ZZ-AABBCCDD
	confs: [defaultconf]

:: problems summary ::
:::: ERRORS
	requested configuration not found in au.gov.asd.tac#third-party-dependencies;working@ZZ-AABBCCDD: [ 'defaultconf' ]

[Auriga2]

Logged #2295 to fix the Undo after Ignore all

[Auriga2]

Fixed constellation-adapters in constellation-app/constellation-adaptors#39

[Auriga2]

Also added a defaultconf here, to avoid specifying conf tag for future dependencies.

[Delphinus8821]

It it working well but in testing I found that it was making the Data Access View take almost a whole minute to open which is not ideal. This happened both with and without Adaptors built.
Steps I tested:
Created a new graph using any of the buttons on the Welcome Page
Attempted to open the Data Access View

Doing the same steps on v3.1 only took about 3 seconds to open the Data Access View

[antares1470]

Minor but I think it might be worth adding a TODO comment to some of the custom class loader parts of the code, just to acknowledge that this is a workaround which can be removed once the dependency clash is no longer an issue. Having a reference in code will make it easier to track than remembering this PR

[Auriga2]

I can recreate the slowness ~30-50s in the spellcheck branch. But it is quite random and I cannot pinpoint anywhere. The logs suggest the spellchecking actions are performed in less than a second. (Can we rely on time stamps?) When I could recreate, a considerable time was taken between discovering data access plugins:

spellcheck branch:

In fact when I merge the spellcheck branch into master, it's consistently faster.
Master without spell checking ~9s
Master with spellcheck branch merged ~9-14s

As Delphinus8821 suggested we should merge and see the performance in a built version before making any more effort?

I've removed the unnecessary while loop, although it didn't affect the slowness.

[sonarqubecloud]

Quality Gate failed

Failed conditions
10.8% Coverage on New Code (required ≥ 80%)
C Reliability Rating on New Code (required ≥ A)
B Maintainability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE