Class MigrationTableGenerator
metadata-migration-3x-4x.json) that LegacyKeyMigrationFilter loads, by joining the
committed 3.x and 4.x {class, field, key} field tables on field identity (Class#field):
- same field, changed key -> a RENAME (auto);
- fields the join can't bridge (moves/drops, or fields renamed on both sides) -> taken from the
adjudicated
migration-overlay.tsv(v4 == DROPPED= 4.x no longer emits it; a third-columnEGRESS_ONLYmarker = the row applies only V4_TO_V3, for 3.x spellings that are ambiguous or unsafe to rewrite on ingest).
org.apache.tika.metadata.*) until the 3.x table is
widened past its v1 (the 3.x snapshot only has core-declared fields, so widening the join side
would never find extra matches). Overlay-target validation is not core-restricted
(TIKA-4816 rename batch): an adjudicated row may rename a bare/legacy key to a Property declared
in a parser module (e.g. geotopic:name in GeoParser, grobid:tei:title in
TEIDOMParser).
Overlay targets validate against metadata-keys.json (the closed-key registry), not the
field table: fieldTable()'s reflection-based field discovery eagerly resolves every
declared field's type, so a class with any field typed on a not-transitively-visible dependency
(e.g. GeoParser's NameFinderME, which pulls in opennlp-tools only via the
provided-scope ctakes-core) throws NoClassDefFoundError and drops the
WHOLE class. The closed-key registry has no such gap: it fully loads each class instead of just
inspecting field types.
Dependency-free by design: tika-core carries the filter and must stay Jackson-free, so both this
generator and the filter emit/parse the flat JSON by hand. MetadataMigrationTableTest
regenerates in-memory and asserts the committed tika-core copy has not drifted.
java ... MigrationTableGenerator <3x-fields.json> <4x-fields.json> <4x-keys.json> <overlay.tsv> <out.json>
-
Method Summary