build!: cleanup dependency tree, shaded JAR, and deploy properly

[c-dilks]

Summary

• cleanup dependencies in all POM files
  • dependency conflicts are now disallowed at compile time (e.g., ejml)
  • added CI job to enforce good dependency practices in general
• cleanup coat-libs JAR file: now 3x smaller
• coatjava now builds 3x faster
• resolved conflicting names coat-lib vs. coat-libs by choosing coat-libs, which is the deployed JAR file's name
• streamlined deployment and versioning process; see docs/dev_notes.md

---

Details

Cleanup Dependency tree

• resolve conflicting dependencies (e.g., ejml, see use the same ejml version used by j4ml #636)
  • adds maven-enforcer-plugin to disallow conflicts at build time (enforce dependency convergence)
  • conflicts which are resolved by choosing an old version (ejml-simple) are now ignored by Dependabot
• resolve transitive dependencies, using mvn dependency:analyze and mvn dependency:tree to detect them
  • doing this was similar to "untangling a knot": removing one transitive dependency would often cause something else to fail
  • added CI job to require no warnings from dependency:analyze, therefore "best" practices for dependencies is now enforced
    • coat-libs, the shaded JAR, is excluded from this test, because dependency:analyze thinks that all of coat-libs's dependencies are "unused"
• remove unused dependencies
  • fixes djl dependency is large #453 by limiting its scope and keeping the only dependencies that are actually used
• dependencyManagement is now used in the parent/pom.xml, to reduce the number of places that common dependencies have to be fully stated
  • in other words, put all the common stuff in one place to reduce repetition
  • e.g., the version of groot is only needed in parent/pom.xml, and all other pom.xml files just need to say its groupId and artifactId

It was more work than just POMs

Most of dependency cleanup was just in the POM files, but some cases I had to edit Java files too:

remove test-scoped dependency org.jlab.jnp:jnp-hipo4 from reconstruction tests

This was strange. If I scope jnp-hipo4 to test in the POM file, as suggested by mvn dependency:analyze, I would get build errors in very specific methods, for example, ECCommon.readStripsHipo:

• my IDE (Eclipse JDT LSP) correctly sees DataEvent as org.jlab.io.base.DataEvent
• the Maven build (maven-compiler-plugin) would get confused and think that DataEvent comes from somewhere in jnp-hipo4, even though this package was not being imported

With the help of @raffaelladevita we found that jnp-hipo4 dependency could actually be removed from all of the impacted reconstruction tests (eb, ec, cvt, alert), so we can avoid the issue altogether.

removal of transitive dependencies exposed "fake" dependencies

Not sure how to best explain this one, but in the process of "untangling" the "knot" of transitive dependencies, I had to also remove some unused imported packages from the following files (see the PR diff for what was removed):

• clas-tracking:
  • DAFilter
  • KFitter
  • KFitterStraight
• cnuphys/swimmer:
  • SwimZ

We have a lot more unused stuff, but that's out of scope of this giant PR. This PR's scope only aimed to make mvn dependency:analyze happy.

Removed hard-coded classpaths

We had hard-coded classpaths in many places. We now set it once in env.sh, and use that version everywhere (that I could find). The new classpath prioritizes the shaded JAR, since there are class overlaps (i.e., the class from the shaded JAR will be used if it is there); doesn't matter though, since the overlapping classes should be identical.

Using Maven deployment plugin

This makes sure that all the files necessary for a Maven repository are produced, and therefore fixes #616.

The deployment process is now streamlined; see docs/dev_notes.md for the procedure.

New deployment tree (for example, releasing version 13.0.0):

    org
    └── jlab
        └── coat
            └── coat-libs
                ├── 13.0.0
                │   ├── coat-libs-13.0.0.jar
                │   ├── coat-libs-13.0.0.jar.md5
                │   ├── coat-libs-13.0.0.jar.sha1
                │   ├── coat-libs-13.0.0.pom
                │   ├── coat-libs-13.0.0.pom.md5
                │   └── coat-libs-13.0.0.pom.sha1
                ├── maven-metadata.xml
                ├── maven-metadata.xml.md5
                └── maven-metadata.xml.sha1

cf. old deployment tree, which lacks hashes, has the wrong metadata files, and forces a non-timestamped snapshot version number:

    org
    └── jlab
        └── coat
            └── coat-libs
                ├── 13.0.0-SNAPSHOT
                │   ├── coat-libs-13.0.0-SNAPSHOT.jar
                │   ├── coat-libs-13.0.0-SNAPSHOT.pom
                │   └── maven-metadata-local.xml
                └── maven-metadata-local.xml

version-bump.sh no longer forces SNAPSHOT versioning

Now version-bump.sh will change the version to whatever you tell it, and does not append -SNAPSHOT for the POM version numbers.

Added more exclusions to the shaded JAR

• Excluding maven metadata fixes the following warning from deployDistribution.sh:

[WARNING] Artifact org.jlab.coat:coat-libs JAR (about to be
installed/deployed) contains Maven Plugin metadata for conflicting
coordinates: org.jacoco:jacoco-maven-plugin. Your JAR contains rogue
Maven Plugin metadata. Possible causes may be: shaded into this JAR some
Maven Plugin or some rogue resource.

• Excluding jacoco since only used here for coverage testing
• Excluding misc files, such as IDE dotfiles
• Renamed coat-lib -> coat-libs, since the shaded JAR filename uses coat-libs
• Several other 3rd party dependencies got excluded after all the dependency "knot" untangling
  • This may break consumers, but they should not be relying on coat-libs to provide those 3rd party dependencies