Scope jython3.test's build resource to stop target/ self-recursing

[khatchad]

Fixes wala/ML#494.

Problem

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

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

Maven copies that 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. Each level contains the module's own *-SNAPSHOT.jar, so disk usage grows exponentially — on a local checkout this had reached 99 GB after a handful of mvn install cycles. See #494 for the full diagnosis.

Fix

Scope the resource via an explicit <includes> filter listing the three entries that need to be on the classpath (META-INF/**, build.properties, logging.properties). This preserves the JAR contents while excluding target/ from the resource scope.

Why an <includes> filter rather than a different <directory>

Looked at the sibling com.ibm.wala.cast.python.test/pom.xml, which scopes its resource as <directory>data</directory> — the cleanest pattern. It doesn't directly apply here because that sibling has no META-INF/ or build.properties at the module root (its only resource is the data/ subdir). This module ships Eclipse PDE metadata that needs to live at the bundle root:

File	Why it needs to be at the bundle root
META-INF/MANIFEST.MF	OSGi bundle manifest (Bundle-SymbolicName, Export-Package, Require-Bundle); Eclipse PDE looks for it at the bundle root
build.properties	Eclipse PDE source/binary mapping (source.. / bin.includes)

Both currently ship in the Maven JAR (verified via jar tf); moving them under a single resources/ subdir would break Eclipse PDE consumers. So the minimal fix that preserves current JAR contents is an explicit <includes> filter.

(The logging.properties entry preserves the current intent — it's a symlink to ../logging.properties, which is broken in master today and silently skipped by Maven; keeping the include is harmless and avoids a behavior delta if the symlink target ever returns.)

Verification

Two consecutive build cycles on the patched module:

mvn -pl jython/com.ibm.wala.cast.python.jython3.test clean install -DskipTests
mvn -pl jython/com.ibm.wala.cast.python.jython3.test install -DskipTests

Result:

$ 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/, no jar-of-jars-of-jars. Total module target/ size 184 KB (vs. 99 GB pre-fix on multi-build accumulations).

Test plan

• Two-cycle local rebuild produces a flat target/classes/ (above).
• Built JAR contains the same set of resources as before (META-INF/MANIFEST.MF, build.properties, META-INF/maven/...).
• CI confirms.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 57.91%. Comparing base (2238db3) to head (5aa2133).

Additional details and impacted files

@@             Coverage Diff              @@
##             master     #493      +/-   ##
============================================
- Coverage     57.93%   57.91%   -0.02%     
+ Complexity      625      624       -1     
============================================
  Files           111      111              
  Lines          7671     7671              
  Branches        856      856              
============================================
- Hits           4444     4443       -1     
- Misses         3049     3050       +1     
  Partials        178      178              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull request overview

Adjusts the Maven resource configuration for jython/com.ibm.wala.cast.python.jython3.test to prevent target/ from being recursively copied into build outputs across repeated builds, addressing the exponential disk growth reported in #494.

Changes:

• Scopes the module’s build resources (still rooted at .) using an explicit <includes> list.
• Limits copied resources to META-INF/**, build.properties, and logging.properties to avoid pulling in target/ on subsequent builds.