build: shade org.jlab.coda:jclara

[c-dilks]

The ECAL calibration suite, namely its ECEngine, inherits from ReconstructionEngine here, which depends on jclara. Since jclara is not in the shaded JAR, the ECAL calibration suite must additionally depend on jclara, even though it does not import any of its classes or directly use them.

To avoid this, let's just shade jclara.

Furthermore, we have been copying our local external-dependencies/jclara-4.3-SNAPSHOT.jar to the "prefix" coatjava/lib/utils/. Adding jclara to the shaded JAR means we no longer need to copy this external-dependencies JAR. Therefore, we can remove the need for the external-dependencies/ JAR altogether.

[baltzell]

We need to be sure CLARA can't pickup stuff in this 4.3 jar. Let's post here what's in it (jar tf), for the record ...

[baltzell]

This reminds me of some old issues ....

1. The embedding of coatjava (and grapes) installations inside a clara installation
2. The (need for) separate coatjava and clara installer scripts
3. This merge request's extension of clara's approach to finding runtime jar dependencies, using a $PATH-like search lookup for $CLARA_PLUGIN_PATH, instead of requiring any assumptions about directory substructure.

Incidentally, I think #3 might also make it easy for coatjava to keep providing rogue jars w/o clara seeing them, relevant to this PR.

[c-dilks]

Here's a diff view between the contents of the JAR files: Diff.html; open it with your browser

• The left pane is 'before this PR' and the right is 'after'
• Lines are 2 words each, object name and JAR file name, sorted by object name
• The only difference is that the clara stuff moves to the shaded JAR (coat-libs-*.jar)

These printouts were produced by:

#!/usr/bin/env bash
set -euo pipefail
for j in $(find coatjava/lib -type f -name '*.jar'); do
  while read o; do
    echo "$o $j"
  done < <(jar tf $j)
done | sort

[c-dilks]

We need to be sure CLARA can't pickup stuff in this 4.3 jar

CLARA's own 6.0 version of the classes are prioritized in the classpath used at runtime; the classpath (from scripts/unix/j_dpe) is

clara/lib   # contains jclara 6.0
clara/plugins/clas12/lib/clas    # this PR would add jclara 4.3 here, in the shaded JAR
clara/plugins/clas12/lib/services
clara/plugins/grapes/lib/core
clara/plugins/grapes/lib/services
clara/services

In theory the 6.0 version will always be used, since it appears first in the class path; however, subtle bugs may still appear with the two versions of clara classes in the classpath, unfortunately.

[c-dilks]

I confirmed we have historically been excluding jclara from the shaded JAR.

[c-dilks]

I can't think of a clean way to do what we want here. The fundamental issue is

• the shaded JAR depends on clas-reco
• clas-reco depends on jclara
• the shaded JAR excludes jclara, therefore, naively clas-reco objects that actually depend on jclara cannot be used
  • including jclara in the shaded JAR solves this issue, but risks conflicting jclara objects in CLARA's own classpath

[c-dilks]

on the other hand, our CLARA CI test passes here, so maybe things will be okay...

[baltzell]

I wouldn't expect any current tests to be sensitive to an overridden clara jar. It probably won't take much to just get this rogue jar out of coatjava.