Parse WebSphere object/relational mapping files as XML

[jkschneider]

What

Adds four extensions to XmlParser.ACCEPTED_FILE_EXTENSIONS:

Extension	Contents
mapxmi	Map.mapxmi — the entity/field to table/column mapping
tblxmi	One per table, root element RDBSchema:RDBTable
dbxmi	The database
schxmi	The schema

These are the object/relational mapping files WebSphere and Rational Application Developer write for container-managed persistence entity beans. They are all XML (XMI 2.0, same family as the already-accepted xmi), they just don't use the .xmi extension.

Why

The current failure is silent, which is the problem.

An estate migrating off container-managed persistence needs these files, because the table and column names live nowhere else — they are not derivable from the deployment descriptor. A real application maps an addressId field to an ADDR_ID column, and a bean named Bonus to a table named XBONUS. You cannot recover that from ejb-jar.xml.

Today those files aren't parsed, so a recipe that reads them resolves nothing — and "this estate has no mapping files" and "we could not read your mapping files" produce an identical result. There is no error, no warning, and nothing in the LST to inspect. The usual workaround is to add plainTextMasks to every build and re-parse the plain text through XmlParser by hand, which every consumer has to rediscover independently.

Evidence

Verified against real published artifacts, not synthesized:

• eclipse-jeetools/webtools.javaee — RAD/Cloudscape test data; mapxmi, tblxmi, schxmi
• healthcit/BIGR — older RAD/Oracle, flat META-INF/Schema/ layout; Map.mapxmi plus ~170 .tblxmi
• JCPuerto/wcs76fp5 — WebSphere Commerce, DB2 LUW; Map.mapxmi alongside the newer .dbm form discussed below

A representative .tblxmi from healthcit/BIGR:

<?xml version="1.0" encoding="UTF-8"?>
<RDBSchema:RDBTable xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:RDBSchema="RDBSchema.xmi" xmi:id="RDBTable_1053626315386" name="ASM" primaryKey="SQLReference_1053626315699">
  <database href="META-INF/Schema/ARDAIS.dbxmi#RDBDatabase_1035204447382"/>
  <schema href="META-INF/Schema/ARDAIS_BIGR.schxmi#RDBSchema_1035204448253"/>
  <columns xmi:type="RDBSchema:RDBColumn" xmi:id="RDBColumn_1053626315386" name="ASM_ID" allowNull="false">
    ...

On .dbm — deliberately excluded

The newer Eclipse Data Tools form of the same mapping is .dbm (root xmi:XMI with LUW:LUWTable/LUW:LUWColumn), and it was a candidate for this PR. I left it out: unlike the other four, .dbm is not specific enough to assume XML. Sampling real .dbm files in the wild turns up plenty that are not:

• interchange/interchange — Interchange dbconf descriptors, e.g. a single line Database news news.txt TAB
• temcdrm/emthub — ATP/EMTP data modules, a fixed-column plain text format
• jsonn/pkgsrc — PLIST.dbm, a pkgsrc packing list

.dbm is also the historical extension for binary DBM/GDBM key-value stores and for DAZ Studio shader files. Accepting it would mean XmlParser claiming files it cannot parse, trading one silent failure for a noisier one. The other four extensions have no such ambiguity — they are WebSphere/RAD-specific and always XMI.

If there's appetite for .dbm it's better as a separate discussion, possibly gated on content sniffing rather than extension alone.

Testing

• websphereTableMapping — round-trips a real-shaped .tblxmi document
• Four new cases in the existing acceptWithValidPaths parameterized test

./gradlew :rewrite-xml:test passes.

https://claude.ai/code/session_0183p9nXiN3wGtiCpNPtyCnJ