mvn -f pom_dlineage.xml package destructively deletes classes from the shared target/classes, breaking the main build

[sqlparser]

Summary

The README documents pom_dlineage.xml as a way to build the DataFlowAnalyzer demo standalone, and honestly discloses that this build currently fails to compile. What it does not disclose is that even attempting it corrupts the main build: because pom_dlineage.xml shares the same target/classes output directory as the root pom.xml (same ${project.basedir}), and only declares one source file, the compiler plugin's incremental-compilation cleanup deletes previously-compiled .class files that aren't part of pom_dlineage.xml's smaller source set — before failing on the compile error. The result: every other demo you had working stops working with ClassNotFoundException until you rerun the main build.

Steps to reproduce

mvn clean package -DskipTests -q
mvn -q exec:java -Dexec.mainClass=demos.listGSPInfo.listGSPInfo -Dexec.classpathScope=runtime
# -> prints version info correctly, e.g. "Version: 4.1.5.15, ..."

mvn -f pom_dlineage.xml package   # fails to compile, exactly as README documents

# now try a demo that worked a moment ago:
mvn -q exec:java -Dexec.mainClass=demos.listGSPInfo.listGSPInfo -Dexec.classpathScope=runtime

Actual output

The second listGSPInfo invocation now fails:

java.lang.ClassNotFoundException: demos.listGSPInfo.listGSPInfo

Checking the output directory confirms the class file is simply gone:

$ ls target/classes/demos/listGSPInfo/
# (empty)

Re-running mvn package -DskipTests restores it, confirming the pom_dlineage.xml attempt is what removed it, not anything to do with listGSPInfo itself.

Impact

A first-time user following the README's own "Building the dlineage demo on its own" section — which gives no warning that this build shares state with the main one — will see every previously-working demo break with a ClassNotFoundException right after trying (and expectedly failing at) the dlineage build, with nothing in the error message pointing back to the real cause. The fix (mvn package -DskipTests again) isn't obvious from the failure.

Suggested fix

Either give pom_dlineage.xml its own separate output directory (e.g. <build><directory>target-dlineage</directory></build>), or add a note to the README's "Building the dlineage demo on its own" section warning that attempting this build can wipe classes from the shared target/classes and that mvn package -DskipTests must be re-run afterward.

Environment

• OpenJDK 21.0.11, Apache Maven 3.8.7, Ubuntu 24.04.3

[sqlparser]

Fixed in b0fff3f: pom_dlineage.xml now builds into its own target-dlineage/ directory instead of sharing the root build's target/classes, so an incremental-compile cleanup in that POM can no longer delete other demos' compiled classes before failing on its own (separately documented) compile error. README updated to match the new jar path.