InjectScipOptions.runMain() (scip-javac/src/main/java/org/scip_code/scip_java/javac/InjectScipOptions.java) reads an incoming @argfile with Files.readAllLines() and calls processArgument() once per line. This assumes each logical compiler argument occupies exactly one line in the argfile.
That assumption breaks for Maven repos whose maven-compiler-plugin <compilerArgs> config contains an <arg> value that itself spans multiple lines (a common formatting style for long plugin option strings — e.g. a long ErrorProne/NullAway -Xplugin:ErrorProne <many -Xep... flags> value, written across several indented lines with trailing backslashes for readability). Maven passes this whole multi-line value through as a single forked-process argument; InjectScipOptions then re-splits it at every embedded newline when reading the argfile, turning what was one argument (e.g. -Xplugin:ErrorProne \) into its own standalone token ending in a bare \. The regenerated argfile then contains that malformed line, and the subsequent javac @$NEW_JAVAC_OPTS call fails with error: invalid flag: \.
Repro: a Maven repo with a maven-compiler-plugin <compilerArgs> <arg> value formatted across multiple lines (a common style when the value is a long ErrorProne/NullAway option string), with <fork>true</fork> (or scip-java's own -Dmaven.compiler.fork=true override in effect). scip-java index fails with error: invalid flag: \ instead of producing an index.
Minimal repro <configuration> for maven-compiler-plugin:
<compilerArgs>
<arg>-Xplugin:ErrorProne \
-XepDisableAllChecks -Xep:NullAway:ERROR \
-XepOpt:NullAway:OnlyNullMarked=true
</arg>
</compilerArgs>Expected: InjectScipOptions should treat the argfile as an actual javac argfile (which supports this kind of formatting) rather than doing a naive per-line split — or should reconstruct whitespace-joined arguments in a way that tolerates multi-line source <arg> values.
InjectScipOptions.runMain()(scip-javac/src/main/java/org/scip_code/scip_java/javac/InjectScipOptions.java) reads an incoming@argfilewithFiles.readAllLines()and callsprocessArgument()once per line. This assumes each logical compiler argument occupies exactly one line in the argfile.That assumption breaks for Maven repos whose
maven-compiler-plugin<compilerArgs>config contains an<arg>value that itself spans multiple lines (a common formatting style for long plugin option strings — e.g. a long ErrorProne/NullAway-Xplugin:ErrorProne <many -Xep... flags>value, written across several indented lines with trailing backslashes for readability). Maven passes this whole multi-line value through as a single forked-process argument;InjectScipOptionsthen re-splits it at every embedded newline when reading the argfile, turning what was one argument (e.g.-Xplugin:ErrorProne \) into its own standalone token ending in a bare\. The regenerated argfile then contains that malformed line, and the subsequentjavac @$NEW_JAVAC_OPTScall fails witherror: invalid flag: \.Repro: a Maven repo with a
maven-compiler-plugin<compilerArgs><arg>value formatted across multiple lines (a common style when the value is a long ErrorProne/NullAway option string), with<fork>true</fork>(or scip-java's own-Dmaven.compiler.fork=trueoverride in effect).scip-java indexfails witherror: invalid flag: \instead of producing an index.Minimal repro
<configuration>formaven-compiler-plugin:Expected:
InjectScipOptionsshould treat the argfile as an actual javac argfile (which supports this kind of formatting) rather than doing a naive per-line split — or should reconstruct whitespace-joined arguments in a way that tolerates multi-line source<arg>values.