`jython3.test`'s build resource recursively copies `target/` into itself, causing exponential disk usage

[khatchad]

Symptom

Repeated mvn install cycles on jython/com.ibm.wala.cast.python.jython3.test cause the module's target/ directory to grow exponentially. On a local checkout this had reached 99 GB before being noticed; the contents are nested copies of the module's own build output:

target/classes/target/classes/target/classes/target/...
                  ↳ <module>-0.0.1-SNAPSHOT.jar (9.9 GB at deeper levels)

Each level contains a 9.9 GB SNAPSHOT jar of jars-of-jars-of-jars (the outer jar packages the inner target/, the next outer jar packages that, etc.).

Root Cause

jython/com.ibm.wala.cast.python.jython3.test/pom.xml declares its build resource as the module root:

<resources>
  <resource>
    <directory>.</directory>
  </resource>
</resources>

Maven copies the contents of the resource directory into target/classes/ on every build. Since target/ is itself at the module root, the second build copies the previous build's target/ into target/classes/target/; the third copies that into target/classes/target/classes/target/; and so on.

Why It Didn't Show Up Sooner

Single-build cycles look fine (one level of target/classes/target/ is hidden inside the jar but isn't huge yet). The blowup is exponential in the number of mvn install cycles, so it's only visible after several rebuilds — a CI run that does one fresh build per checkout never accumulates it.

Sibling Pattern

com.ibm.wala.cast.python.test/pom.xml does it correctly with <directory>data</directory> (scoped to a specific subdirectory). That sibling has no Eclipse PDE bundle metadata at the module root, so the single-subdir pattern works there.

jython3.test ships Eclipse PDE bundle metadata at the module root (META-INF/MANIFEST.MF, build.properties) that downstream OSGi consumers expect to find at the bundle root. So a direct port of the sibling pattern would either drop those resources or break Eclipse PDE.

Fix

PR #493 scopes the resource via an explicit <includes> filter (META-INF/**, build.properties, logging.properties). That preserves the current JAR contents while excluding target/ from the resource scope.

Verification

Two consecutive build cycles on the patched module:

$ ls jython/com.ibm.wala.cast.python.jython3.test/target/classes/
META-INF
build.properties
com

$ du -sh jython/com.ibm.wala.cast.python.jython3.test/target
184K

No self-referential target/classes/target/; total module target/ size 184 KB (vs. 99 GB pre-fix on multi-build accumulations).