Consume jnp-hipo4 4.5 from the hipo-java package registry

[mathieuouillon]

jnp-hipo4 is now built and released from its own repository,
code.jlab.org/hallb/clas12/hipo-java,
rather than being cut from the monolithic jnp tree. This points the dependency
at 4.5 from that project's package registry.

<repository>
  <id>clas12-hipo-java</id>
  <url>https://code.jlab.org/api/v4/projects/919/packages/maven</url>
</repository>

The registry is public, so this needs no credentials or settings.xml.

Two things this changes beyond the coordinate

exp4j is governed by our pin again. The old clasweb artifact was a fat jar
bundling exp4j, lz4 and xxhash. The net.objecthunter:exp4j:0.4.8 pinned in
the root pom — specifically to resolve the jnp-hipo / jnp-hipo4 conflict, per
docs/dependency_conflicts.md — was therefore being shadowed by a copy inside the
jar. 4.5 publishes a plain jar and declares its dependencies normally:

\- org.jlab.jnp:jnp-hipo4:jar:4.5:compile
   +- net.objecthunter:exp4j:jar:0.4.8:compile
   \- org.lz4:lz4-java:jar:1.8.0:compile

maven-enforcer's DependencyConvergence passes.

Fewer duplicate classes on the classpath. The fat jar also carried
org.jlab.jnp.{matrix,ascii,readers} and MigLayout, all of which jnp-hipo
already provides — so they were present twice and classpath order decided the
winner. 4.5 drops them. Every one this project actually imports (17
org.jlab.jnp.matrix, 17 org.jlab.jnp.utils.*) resolves from jnp-hipo, which
we already depend on. net.miginfocom, org.jlab.jnp.ascii and
org.jlab.jnp.readers have zero imports here.

No org.jlab.jnp.hipo4 class is missing in 4.5 — the API surface is complete.

Verification

Compared against an unmodified development baseline, same commands:

	baseline 4.3-SNAPSHOT	this branch (4.5)
build	49 modules SUCCESS	49 modules SUCCESS
compiled	—	1620 source files → 2014 classes, 52 jars
tests	14 run, 0 failures, 1 error	14 run, 0 failures, 1 error
the error	DCReconstructionTest	DCReconstructionTest — same test, same cause

That error is FileNotFoundException: TORUS map not found at ../../etc/data/magfield/Symm_torus_r2501_phi16_z251_24Apr2018.dat (the NPE is its
downstream effect) — a field map absent from a fresh clone. It reproduces
identically without this change, which is the only reason it can be set aside.

Notes for reviewers

• If you fetched jnp-hipo4:4.5 before 2026-07-25 09:19 UTC you may have a
  cached fat jar from a packaging bug in the first upload (the assembly was
  deployed as the main artifact). It has been corrected and re-published. Clear
  ~/.m2/repository/org/jlab/jnp/jnp-hipo4/4.5 if the tree looks wrong; a correct
  main jar is 127 classes with no net/* packages.
• Pre-existing and not addressed here: 48 classes still overlap between
  jnp-hipo and jnp-hipo4 (org.jlab.jnp.utils.{json,file,data,…}), since
  hipo-java ships its own copies. The old jar duplicated them too, so this is not
  a regression — but classpath order still decides which JsonObject wins.
  Removing that overlap means hipo-java dropping org/jlab/jnp/utils in favour of
  depending on jnp-hipo, which is a larger decision than this PR.

[c-dilks]

This looks great, thank you so much for doing this!

[mathieuouillon]

I tested both halves of the concern, clearing the local ~/.m2
entry each time so nothing was answering from cache.

The entry is load-bearing. Drop it and the build fails outright:

[ERROR] Could not find artifact org.jlab.jnp:jnp-hipo4:jar:4.5
        in clas12maven (https://clasweb.jlab.org/.clas12maven)

after walking clas12maven → jnp-maven → central. So 4.5 exists nowhere but
project 919 today, and the shadowing risk is prospective rather than current —
clasweb only carries the older fat-jar versions.

Order really does decide, and silently. I put a deliberately fake
org.jlab.jnp:jnp-hipo4:4.5 (a 211-byte jar with a marker file) in a file://
repo and varied only its position, resolving into a throwaway local repo:

listed first	resolved
the impostor	the impostor — 211 bytes
clas12-hipo-java	the real jar — 310,609 bytes

When the impostor won, Maven emitted nothing at all: no warning, no
conflict notice, exit 0. That is the case listing this repository first
prevents, and it would not have announced itself.