[jira] [Comment Edited] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847508#comment-17847508
]
Mikkel Kjeldsen edited comment on MINVOKER-351 at 5/18/24 11:35 AM:
{quote}
So this output shows a lot of problems:
* You failed to provide the conditions: Maven version, Java version, plugin
versions
* The test requires Java 11, what for? Is that a JAva version specific issue?
* The IT passes with Maven 3.8.x, but fails with 3.9.x.
* Important plugins haven't been pinned
{quote}
The behavior in Maven 3.8.x is interesting because it suggests a different
error in the test execution: it claims to run the test yet reports 0 tests run,
which could well explain the missing output. I can see the class being compiled
but I am unable to glean from the output of {{-Dinvoker.debug}} whether it
confirms that hypothesis.
In any case, I suspect this is just an artifact of using JUnit 5. Maven 3.6.3
and up combined with [m-surefire-p
2.22.0|https://blogsarchive.apache.org/maven/entry/apache-maven-surefire-plugin-2]
and up behave as expected, while m-surefire-p 2.21.0 in the same versions of
Maven fail to produce the expected output and Maven 3.8.8 apparently defaults
to m-surefire-p 2.12.4. Perhaps because of SUREFIRE-1330.
Besides this, under the reasonable assumption that no exceptional branching for
these component versions occurs, the versions of
* Java
* Maven
* Surefire
have no bearing on the behavior of m-invoker-p's callstacks, which ultimately
and independently end up producing insufficiently sanitized output. The
question is only whether to...
# ignore the issue
# fix the issue locally inside m-invoker-p
# punt the issue upstream to the writer
was (Author: JIRAUSER303566):
{quote}
So this output shows a lot of problems:
* You failed to provide the conditions: Maven version, Java version, plugin
versions
* The test requires Java 11, what for? Is that a JAva version specific issue?
* The IT passes with Maven 3.8.x, but fails with 3.9.x.
* Important plugins haven't been pinned
{quote}
The behavior in Maven 3.8.x is interesting because it suggests a different
error in the test execution: it claims to run the test yet reports 0 tests run,
which could well explain the missing output. I can see the class being compiled
but I am unable to glean from the output of {{-Dinvoker.debug}} whether it
confirms that hypothesis.
In any case, I suspect this is just an artifact of using JUnit 5. Maven 3.6.3
and up combined with [m-surefire-p
2.22.0|https://blogsarchive.apache.org/maven/entry/apache-maven-surefire-plugin-2]
and up behave as expected, while m-surefire-p 2.21.0 in the same versions of
Maven fail to produce the expected output. Perhaps because of SUREFIRE-1330.
Besides this, under the reasonable assumption that no exceptional branching for
these component versions occurs, the versions of
* Java
* Maven
* Surefire
have no bearing on the behavior of m-invoker-p's callstacks, which ultimately
and independently end up producing insufficiently sanitized output. The
question is only whether to...
# ignore the issue
# fix the issue locally inside m-invoker-p
# punt the issue upstream to the writer
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847508#comment-17847508
]
Mikkel Kjeldsen commented on MINVOKER-351:
--
{quote}
So this output shows a lot of problems:
* You failed to provide the conditions: Maven version, Java version, plugin
versions
* The test requires Java 11, what for? Is that a JAva version specific issue?
* The IT passes with Maven 3.8.x, but fails with 3.9.x.
* Important plugins haven't been pinned
{quote}
The behavior in Maven 3.8.x is interesting because it suggests a different
error in the test execution: it claims to run the test yet reports 0 tests run,
which could well explain the missing output. I can see the class being compiled
but I am unable to glean from the output of {{-Dinvoker.debug}} whether it
confirms that hypothesis.
In any case, I suspect this is just an artifact of using JUnit 5. Maven 3.6.3
and up combined with [m-surefire-p
2.22.0|https://blogsarchive.apache.org/maven/entry/apache-maven-surefire-plugin-2]
and up behave as expected, while m-surefire-p 2.21.0 in the same versions of
Maven fail to produce the expected output. Perhaps because of SUREFIRE-1330.
Besides this, under the reasonable assumption that no exceptional branching for
these component versions occurs, the versions of
* Java
* Maven
* Surefire
have no bearing on the behavior of m-invoker-p's callstacks, which ultimately
and independently end up producing insufficiently sanitized output. The
question is only whether to...
# ignore the issue
# fix the issue locally inside m-invoker-p
# punt the issue upstream to the writer
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847368#comment-17847368
]
Mikkel Kjeldsen commented on MINVOKER-351:
--
[~michael-o], curious output. This is the expected output:
{noformat}
~ $ cd $(mktemp -d)
/tmp/tmp.0HU4NpMJCX $ wget --quiet
https://issues.apache.org/jira/secure/attachment/13068809/minvoker-351.tar.gz
/tmp/tmp.0HU4NpMJCX $ tar vxf minvoker-351.tar.gz
minvoker-351/
minvoker-351/pom.xml
minvoker-351/src/
minvoker-351/src/it/
minvoker-351/src/it/minvoker-351/
minvoker-351/src/it/minvoker-351/pom.xml
minvoker-351/src/it/minvoker-351/src/
minvoker-351/src/it/minvoker-351/src/test/
minvoker-351/src/it/minvoker-351/src/test/java/
minvoker-351/src/it/minvoker-351/src/test/java/example/
minvoker-351/src/it/minvoker-351/src/test/java/example/minvoker351/
minvoker-351/src/it/minvoker-351/src/test/java/example/minvoker351/ExampleTest.java
minvoker-351/src/it/minvoker-351/src/main/
minvoker-351/src/it/minvoker-351/src/main/java/
minvoker-351/src/it/minvoker-351/src/main/java/example/
minvoker-351/src/it/minvoker-351/src/main/java/example/minvoker351/
minvoker-351/src/it/minvoker-351/src/main/java/example/minvoker351/Example.java
/tmp/tmp.0HU4NpMJCX $ cd minvoker-351/
/tmp/tmp.0HU4NpMJCX/minvoker-351 $ mvn --version
Apache Maven 3.9.6
Maven home: /usr/share/maven
Java version: 21.0.2, vendor: N/A, runtime: /usr/lib64/jvm/java-21-openjdk-21
Default locale: en_DK, platform encoding: UTF-8
OS name: "linux", version: "5.14.21-150500.55.52-default", arch: "amd64",
family: "unix"
/tmp/tmp.0HU4NpMJCX/minvoker-351 $ mvn verify site
[INFO] Scanning for projects...
[INFO]
[INFO] --< example.minvoker351:minvoker-351 >--
[INFO] Building minvoker-351 1.0-SNAPSHOT
[INFO] from pom.xml
[INFO] [ jar ]-
[INFO]
[INFO] --- resources:3.3.1:resources (default-resources) @ minvoker-351 ---
[INFO] skip non existing resourceDirectory
/tmp/tmp.0HU4NpMJCX/minvoker-351/src/main/resources
[INFO]
[INFO] --- compiler:3.11.0:compile (default-compile) @ minvoker-351 ---
[INFO] No sources to compile
[INFO]
[INFO] --- resources:3.3.1:testResources (default-testResources) @ minvoker-351
---
[INFO] skip non existing resourceDirectory
/tmp/tmp.0HU4NpMJCX/minvoker-351/src/test/resources
[INFO]
[INFO] --- compiler:3.11.0:testCompile (default-testCompile) @ minvoker-351 ---
[INFO] No sources to compile
[INFO]
[INFO] --- surefire:3.2.2:test (default-test) @ minvoker-351 ---
[INFO] No tests to run.
[INFO]
[INFO] --- jar:3.3.0:jar (default-jar) @ minvoker-351 ---
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO] Building jar:
/tmp/tmp.0HU4NpMJCX/minvoker-351/target/minvoker-351-1.0-SNAPSHOT.jar
[INFO]
[INFO] --- invoker:3.6.1:install (integration-test) @ minvoker-351 ---
[INFO] Installing
/tmp/tmp.0HU4NpMJCX/minvoker-351/target/minvoker-351-1.0-SNAPSHOT.jar to
/tmp/tmp.0HU4NpMJCX/minvoker-351/target/local-repo/example/minvoker351/minvoker-351/1.0-SNAPSHOT/minvoker-351-1.0-SNAPSHOT.jar
[INFO] Installing /tmp/tmp.0HU4NpMJCX/minvoker-351/pom.xml to
/tmp/tmp.0HU4NpMJCX/minvoker-351/target/local-repo/example/minvoker351/minvoker-351/1.0-SNAPSHOT/minvoker-351-1.0-SNAPSHOT.pom
[INFO]
[INFO] --- invoker:3.6.1:run (integration-test) @ minvoker-351 ---
[INFO] Building: minvoker-351/pom.xml
[INFO] minvoker-351/pom.xml . SUCCESS
(6.021 s)
[INFO] -
[INFO] Build Summary:
[INFO] Passed: 1, Failed: 0, Errors: 0, Skipped: 0
[INFO] -
[INFO]
[INFO] --- site:3.12.1:site (default-site) @ minvoker-351 ---
[INFO] configuring report plugin
org.apache.maven.plugins:maven-project-info-reports-plugin:3.5.0
[INFO] 15 reports detected for maven-project-info-reports-plugin:3.5.0:
ci-management, dependencies, dependency-info, dependency-management,
distribution-management, index, issue-management, licenses, mailing-lists,
modules, plugin-management, plugins, scm, summary, team
[INFO] configuring report plugin
org.apache.maven.plugins:maven-surefire-report-plugin:3.2.5
[INFO] preparing maven-surefire-report-plugin:report report requires
'[surefire]test' forked phase execution
[INFO]
[INFO] >>> surefire-report:3.2.5:report > [surefire]test @ minvoker-351 >>>
[INFO]
[INFO] --- resources:3.3.1:resources (default-resources) @ minvoker-351 ---
[INFO] skip non existing resourceDirectory
/tmp/tmp.0HU4NpMJCX/minvoker-351/src/main/resources
[INFO]
[INFO] --- compiler:3.11.0:compile (default-compile) @ minvoker-351 ---
[INFO] No sources to compile
[INFO]
[INFO] --- resources:3.3.1:testResources (default-testResources) @ minvoker-351
---
[INFO] skip non existing resourceDirectory
/tmp/tmp.0HU4NpMJCX/minvoker-351/src/test/resources
[INFO]
[INFO] ---
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845665#comment-17845665
]
Mikkel Kjeldsen commented on MINVOKER-351:
--
[~sjaranowski], see [^minvoker-351.tar.gz] . {{verify}} successfully runs an
Invoker test and generates a JUnit test report. The test prints ASCII to
standard out; some of those characters are not allowed in XML (IIRC there are
more). {{site}} then fails to generate a Surefire report.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Reporter: Mikkel Kjeldsen
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible, because any
[jira] [Updated] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikkel Kjeldsen updated MINVOKER-351:
-
Attachment: minvoker-351.tar.gz
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Reporter: Mikkel Kjeldsen
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible, because any existing user that
> would be affected by it would already have unparseable JUnit reports.
> * I _believe_ that Java's {{j.u.r.Pattern}} can trivially express the
> complement of allowed characters but there may exist more efficient solutions.
> * Consider also applying this transformation to
[jira] [Commented] (MCOMPILER-572) Multi-line does not work on Windows when forked
[
https://issues.apache.org/jira/browse/MCOMPILER-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17811131#comment-17811131
]
Mikkel Kjeldsen commented on MCOMPILER-572:
---
bq. The value you have provided deliberately contains a space?
It deliberately contains an escaped line break, which {{javac}} will reliably
interpret as a single argument, because that's how the {{-Xplugin}} option must
be used. In other words, a hypothetical
{code:xml}
-Xplugin:ErrorProne
-Xep:DeadException:WARN
{code}
is an incorrect invocation of {{javac}}.
bq. If so, why are you try to add a line separator to it?
Because, not obvious from the reproduction sample I supplied, the Error Prone
plugin accepts _a lot_ of arguments and these are much, much easier to organize
across multiple lines. One example of that I have handy is
{{jackson-databind}}, which stretches its configuration over 70 lines, at
https://github.com/FasterXML/jackson-databind/blob/2.17/pom.xml#L468-L541;
although {{jackson-databind}} uses the in-process compiler which doesn't
require escaping line breaks.
bq. There is no code in this plugin to manage that.
I am aware of this. All that code is in {{plexus-compiler}} (specifically its
{{JavacCompiler}}), as I have stated. However, I am a consumer of
{{maven-compiler-plugin}} wherein the error manifests, not of
{{plexus-compiler}} wherein the error originates, so only filing a ticket with
{{plexus-compiler}} is insufficient.
> Multi-line does not work on Windows when forked
> -
>
> Key: MCOMPILER-572
> URL: https://issues.apache.org/jira/browse/MCOMPILER-572
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.12.1
>Reporter: Mikkel Kjeldsen
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Versions of {{maven-compiler-plugin}} that rely on
> {{plexus-compiler-2.14.2}}, hereunder {{maven-compiler-plugin-3.12.1}},
> cannot pass multi-line compiler arguments to a forked {{javac}} on Windows in
> any way. Further, attempting to do so produces a non-obvious and difficult to
> troubleshoot error. This error does not manifest outside of Windows, nor does
> it manifest on Windows if the compiler is not forked.
> This bug is a downstream version of
> https://github.com/codehaus-plexus/plexus-compiler/issues/351, filed in
> response to https://github.com/google/error-prone/issues/4256.
> The sample POM
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> example.multi-line-fork-crash
> minimally-reproducible
> 1.0-SNAPSHOT
>
> 21
> 3.12.1
>
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> ${maven-compiler-plugin.version}
>
> true
>
>
> -Xplugin:ErrorProne \
> -Xep:DeadException:WARN
>
>
>
>
>
>
> {code}
> _should_ fail to compile with the error
> {noformat}
> plug-in not found: ErrorProne
> {noformat}
> but instead fails with the error
> {noformat}
> error: invalid flag: -Xep:DeadException
> {noformat}
> because {{plexus-compiler}} indiscriminately translates the \ to / and breaks
> {{javac}} 's multi-line argument support.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MCOMPILER-572) Multi-line does not work on Windows when forked
[
https://issues.apache.org/jira/browse/MCOMPILER-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17810956#comment-17810956
]
Mikkel Kjeldsen edited comment on MCOMPILER-572 at 1/25/24 5:06 PM:
[~michael-o], "arg line" is not a term defined by the documentation you
reference, and {{-Xplugin:ErrorProne -Xep:DeadException:WARN}} is a single
argument, not two arguments. Please advise.
Let me reiterate that this is just a tracking issue. There is nothing for
{{maven-compiler-plugin}} to fix except upgrading {{plexus-compiler}} to a
version that fixes the discrepant behaviour -- hopefully in a way that allows
the missing functionality -- once such a version exists.
was (Author: JIRAUSER303566):
[~michael-o], "arg line" is not a term defined by the documentation you
reference, and {{-Xplugin:ErrorProne -Xep:DeadException:WARN}} is a single
argument, not two arguments. Please advise.
> Multi-line does not work on Windows when forked
> -
>
> Key: MCOMPILER-572
> URL: https://issues.apache.org/jira/browse/MCOMPILER-572
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.12.1
>Reporter: Mikkel Kjeldsen
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Versions of {{maven-compiler-plugin}} that rely on
> {{plexus-compiler-2.14.2}}, hereunder {{maven-compiler-plugin-3.12.1}},
> cannot pass multi-line compiler arguments to a forked {{javac}} on Windows in
> any way. Further, attempting to do so produces a non-obvious and difficult to
> troubleshoot error. This error does not manifest outside of Windows, nor does
> it manifest on Windows if the compiler is not forked.
> This bug is a downstream version of
> https://github.com/codehaus-plexus/plexus-compiler/issues/351, filed in
> response to https://github.com/google/error-prone/issues/4256.
> The sample POM
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> example.multi-line-fork-crash
> minimally-reproducible
> 1.0-SNAPSHOT
>
> 21
> 3.12.1
>
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> ${maven-compiler-plugin.version}
>
> true
>
>
> -Xplugin:ErrorProne \
> -Xep:DeadException:WARN
>
>
>
>
>
>
> {code}
> _should_ fail to compile with the error
> {noformat}
> plug-in not found: ErrorProne
> {noformat}
> but instead fails with the error
> {noformat}
> error: invalid flag: -Xep:DeadException
> {noformat}
> because {{plexus-compiler}} indiscriminately translates the \ to / and breaks
> {{javac}} 's multi-line argument support.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MCOMPILER-572) Multi-line does not work on Windows when forked
[
https://issues.apache.org/jira/browse/MCOMPILER-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17810956#comment-17810956
]
Mikkel Kjeldsen edited comment on MCOMPILER-572 at 1/25/24 4:03 PM:
[~michael-o], "arg line" is not a term defined by the documentation you
reference, and {{-Xplugin:ErrorProne -Xep:DeadException:WARN}} is a single
argument, not two arguments. Please advise.
was (Author: JIRAUSER303566):
[~michael-o], "arg line" is not a term defined by the documentation you
reference, and {{-Xplugin:ErrorProne -Xep:DeadException:WARN}} is a single
argument. Please advise.
> Multi-line does not work on Windows when forked
> -
>
> Key: MCOMPILER-572
> URL: https://issues.apache.org/jira/browse/MCOMPILER-572
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.12.1
>Reporter: Mikkel Kjeldsen
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Versions of {{maven-compiler-plugin}} that rely on
> {{plexus-compiler-2.14.2}}, hereunder {{maven-compiler-plugin-3.12.1}},
> cannot pass multi-line compiler arguments to a forked {{javac}} on Windows in
> any way. Further, attempting to do so produces a non-obvious and difficult to
> troubleshoot error. This error does not manifest outside of Windows, nor does
> it manifest on Windows if the compiler is not forked.
> This bug is a downstream version of
> https://github.com/codehaus-plexus/plexus-compiler/issues/351, filed in
> response to https://github.com/google/error-prone/issues/4256.
> The sample POM
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> example.multi-line-fork-crash
> minimally-reproducible
> 1.0-SNAPSHOT
>
> 21
> 3.12.1
>
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> ${maven-compiler-plugin.version}
>
> true
>
>
> -Xplugin:ErrorProne \
> -Xep:DeadException:WARN
>
>
>
>
>
>
> {code}
> _should_ fail to compile with the error
> {noformat}
> plug-in not found: ErrorProne
> {noformat}
> but instead fails with the error
> {noformat}
> error: invalid flag: -Xep:DeadException
> {noformat}
> because {{plexus-compiler}} indiscriminately translates the \ to / and breaks
> {{javac}} 's multi-line argument support.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MCOMPILER-572) Multi-line does not work on Windows when forked
[
https://issues.apache.org/jira/browse/MCOMPILER-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17810956#comment-17810956
]
Mikkel Kjeldsen edited comment on MCOMPILER-572 at 1/25/24 4:02 PM:
[~michael-o], "arg line" is not a term defined by the documentation you
reference, and {{-Xplugin:ErrorProne -Xep:DeadException:WARN}} is a single
argument. Please advise.
was (Author: JIRAUSER303566):
[~michael-o], "arg line" is not a term defined by the documentation you
reference. Please advise.
> Multi-line does not work on Windows when forked
> -
>
> Key: MCOMPILER-572
> URL: https://issues.apache.org/jira/browse/MCOMPILER-572
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.12.1
>Reporter: Mikkel Kjeldsen
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Versions of {{maven-compiler-plugin}} that rely on
> {{plexus-compiler-2.14.2}}, hereunder {{maven-compiler-plugin-3.12.1}},
> cannot pass multi-line compiler arguments to a forked {{javac}} on Windows in
> any way. Further, attempting to do so produces a non-obvious and difficult to
> troubleshoot error. This error does not manifest outside of Windows, nor does
> it manifest on Windows if the compiler is not forked.
> This bug is a downstream version of
> https://github.com/codehaus-plexus/plexus-compiler/issues/351, filed in
> response to https://github.com/google/error-prone/issues/4256.
> The sample POM
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> example.multi-line-fork-crash
> minimally-reproducible
> 1.0-SNAPSHOT
>
> 21
> 3.12.1
>
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> ${maven-compiler-plugin.version}
>
> true
>
>
> -Xplugin:ErrorProne \
> -Xep:DeadException:WARN
>
>
>
>
>
>
> {code}
> _should_ fail to compile with the error
> {noformat}
> plug-in not found: ErrorProne
> {noformat}
> but instead fails with the error
> {noformat}
> error: invalid flag: -Xep:DeadException
> {noformat}
> because {{plexus-compiler}} indiscriminately translates the \ to / and breaks
> {{javac}} 's multi-line argument support.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-572) Multi-line does not work on Windows when forked
[
https://issues.apache.org/jira/browse/MCOMPILER-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17810956#comment-17810956
]
Mikkel Kjeldsen commented on MCOMPILER-572:
---
[~michael-o], "arg line" is not a term defined by the documentation you
reference. Please advise.
> Multi-line does not work on Windows when forked
> -
>
> Key: MCOMPILER-572
> URL: https://issues.apache.org/jira/browse/MCOMPILER-572
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.12.1
>Reporter: Mikkel Kjeldsen
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Versions of {{maven-compiler-plugin}} that rely on
> {{plexus-compiler-2.14.2}}, hereunder {{maven-compiler-plugin-3.12.1}},
> cannot pass multi-line compiler arguments to a forked {{javac}} on Windows in
> any way. Further, attempting to do so produces a non-obvious and difficult to
> troubleshoot error. This error does not manifest outside of Windows, nor does
> it manifest on Windows if the compiler is not forked.
> This bug is a downstream version of
> https://github.com/codehaus-plexus/plexus-compiler/issues/351, filed in
> response to https://github.com/google/error-prone/issues/4256.
> The sample POM
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> example.multi-line-fork-crash
> minimally-reproducible
> 1.0-SNAPSHOT
>
> 21
> 3.12.1
>
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> ${maven-compiler-plugin.version}
>
> true
>
>
> -Xplugin:ErrorProne \
> -Xep:DeadException:WARN
>
>
>
>
>
>
> {code}
> _should_ fail to compile with the error
> {noformat}
> plug-in not found: ErrorProne
> {noformat}
> but instead fails with the error
> {noformat}
> error: invalid flag: -Xep:DeadException
> {noformat}
> because {{plexus-compiler}} indiscriminately translates the \ to / and breaks
> {{javac}} 's multi-line argument support.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MCOMPILER-572) Multi-line does not work on Windows when forked
[
https://issues.apache.org/jira/browse/MCOMPILER-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikkel Kjeldsen updated MCOMPILER-572:
--
Description:
Versions of {{maven-compiler-plugin}} that rely on {{plexus-compiler-2.14.2}},
hereunder {{maven-compiler-plugin-3.12.1}}, cannot pass multi-line compiler
arguments to a forked {{javac}} on Windows in any way. Further, attempting to
do so produces a non-obvious and difficult to troubleshoot error. This error
does not manifest outside of Windows, nor does it manifest on Windows if the
compiler is not forked.
This bug is a downstream version of
https://github.com/codehaus-plexus/plexus-compiler/issues/351, filed in
response to https://github.com/google/error-prone/issues/4256.
The sample POM
{code:xml}
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0
example.multi-line-fork-crash
minimally-reproducible
1.0-SNAPSHOT
21
3.12.1
org.apache.maven.plugins
maven-compiler-plugin
${maven-compiler-plugin.version}
true
-Xplugin:ErrorProne \
-Xep:DeadException:WARN
{code}
_should_ fail to compile with the error
{noformat}
plug-in not found: ErrorProne
{noformat}
but instead fails with the error
{noformat}
error: invalid flag: -Xep:DeadException
{noformat}
because {{plexus-compiler}} indiscriminately translates the \ to / and breaks
{{javac}} 's multi-line argument support.
was:
Versions of {{maven-compiler-plugin}} that rely on {{plexus-compiler-2.14.2}},
hereunder {{maven-compiler-plugin-3.12.1}}, cannot pass multi-line compiler
arguments to a forked {{javac}} on Windows in any way. Further, attempting to
do so produces a non-obvious and difficult to troubleshoot error. This error
does not manifest outside of Windows, nor does it manifest on Windows if the
compiler is not forked.
This bug is a downstream version of
https://github.com/codehaus-plexus/plexus-compiler/issues/351 (Forking
JavacCompiler breaks multiline arguments on Windows), filed in response to
https://github.com/google/error-prone/issues/4256 (Maven multi-line does
not work on Windows when ed).
The sample POM
{code:xml}
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0
example.multi-line-fork-crash
minimally-reproducible
1.0-SNAPSHOT
21
3.12.1
org.apache.maven.plugins
maven-compiler-plugin
${maven-compiler-plugin.version}
true
-Xplugin:ErrorProne \
-Xep:DeadException:WARN
{code}
_should_ fail to compile with the error
{noformat}
plug-in not found: ErrorProne
{noformat}
but instead fails with the error
{noformat}
error: invalid flag: -Xep:DeadException
{noformat}
because {{plexus-compiler}} indiscriminately translates the \ to / and breaks
{{javac}} 's multi-line argument support.
> Multi-line does not work on Windows when forked
> -
>
> Key: MCOMPILER-572
> URL: https://issues.apache.org/jira/browse/MCOMPILER-572
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.12.1
>Reporter: Mikkel Kjeldsen
>Priority: Major
>
> Versions of {{maven-compiler-plugin}} that rely on
> {{plexus-compiler-2.14.2}}, hereunder {{maven-compiler-plugin-3.12.1}},
> cannot pass multi-line compiler arguments to a forked {{javac}} on Windows in
> any way. Further, attempting to do so produces a non-obvious and difficult to
> troubleshoot error. This error does not manifest outside of Windows, nor does
> it manifest on Windows if the compiler is not forked.
> This bug is a downstream version of
> https://github.com/codehaus-plexus/plexus-compiler/issues/351, filed in
> response to https://github.com/google/error-prone/issues/4256.
> The sample POM
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> example.multi-line-fork-crash
> minimally-reproducible
> 1.0-SNAPSHOT
>
> 21
> 3.12.1
>
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> ${maven-compiler-plugin.version}
>
> true
>
>
> -Xplugin:ErrorProne \
> -Xep:DeadException:WARN
>
[jira] [Updated] (MCOMPILER-572) Multi-line does not work on Windows when forked
[
https://issues.apache.org/jira/browse/MCOMPILER-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikkel Kjeldsen updated MCOMPILER-572:
--
Description:
Versions of {{maven-compiler-plugin}} that rely on {{plexus-compiler-2.14.2}},
hereunder {{maven-compiler-plugin-3.12.1}}, cannot pass multi-line compiler
arguments to a forked {{javac}} on Windows in any way. Further, attempting to
do so produces a non-obvious and difficult to troubleshoot error. This error
does not manifest outside of Windows, nor does it manifest on Windows if the
compiler is not forked.
This bug is a downstream version of
https://github.com/codehaus-plexus/plexus-compiler/issues/351 (Forking
JavacCompiler breaks multiline arguments on Windows), filed in response to
https://github.com/google/error-prone/issues/4256 (Maven multi-line does
not work on Windows when ed).
The sample POM
{code:xml}
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0
example.multi-line-fork-crash
minimally-reproducible
1.0-SNAPSHOT
21
3.12.1
org.apache.maven.plugins
maven-compiler-plugin
${maven-compiler-plugin.version}
true
-Xplugin:ErrorProne \
-Xep:DeadException:WARN
{code}
_should_ fail to compile with the error
{noformat}
plug-in not found: ErrorProne
{noformat}
but instead fails with the error
{noformat}
error: invalid flag: -Xep:DeadException
{noformat}
because {{plexus-compiler}} indiscriminately translates the \ to / and breaks
{{javac}} 's multi-line argument support.
was:
Versions of {{maven-compiler-plugin}} that rely on {{plexus-compiler-2.14.2}},
hereunder {{maven-compiler-plugin-3.12.1}}, cannot pass multi-line compiler
arguments to a forked {{javac}} on Windows in any way. Further, attempting to
do so produces a non-obvious and difficult to troubleshoot error. This error
does not manifest outside of Windows, nor does it manifest on Windows if the
compiler is not forked.
This bug is a downstream version of
https://github.com/codehaus-plexus/plexus-compiler/issues/351 (Forking
JavacCompiler breaks multiline arguments on Windows).
The sample POM
{code:xml}
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0
example.multi-line-fork-crash
minimally-reproducible
1.0-SNAPSHOT
21
3.12.1
org.apache.maven.plugins
maven-compiler-plugin
${maven-compiler-plugin.version}
true
-Xplugin:ErrorProne \
-Xep:DeadException:WARN
{code}
_should_ fail to compile with the error
{noformat}
plug-in not found: ErrorProne
{noformat}
but instead fails with the error
{noformat}
error: invalid flag: -Xep:DeadException
{noformat}
because {{plexus-compiler}} indiscriminately translates the \ to / and breaks
{{javac}} 's multi-line argument support.
> Multi-line does not work on Windows when forked
> -
>
> Key: MCOMPILER-572
> URL: https://issues.apache.org/jira/browse/MCOMPILER-572
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.12.1
>Reporter: Mikkel Kjeldsen
>Priority: Major
>
> Versions of {{maven-compiler-plugin}} that rely on
> {{plexus-compiler-2.14.2}}, hereunder {{maven-compiler-plugin-3.12.1}},
> cannot pass multi-line compiler arguments to a forked {{javac}} on Windows in
> any way. Further, attempting to do so produces a non-obvious and difficult to
> troubleshoot error. This error does not manifest outside of Windows, nor does
> it manifest on Windows if the compiler is not forked.
> This bug is a downstream version of
> https://github.com/codehaus-plexus/plexus-compiler/issues/351 (Forking
> JavacCompiler breaks multiline arguments on Windows), filed in response to
> https://github.com/google/error-prone/issues/4256 (Maven multi-line
> does not work on Windows when ed).
> The sample POM
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> example.multi-line-fork-crash
> minimally-reproducible
> 1.0-SNAPSHOT
>
> 21
> 3.12.1
>
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> ${maven-compiler-plugin.version}
>
>
[jira] [Created] (MCOMPILER-572) Multi-line does not work on Windows when forked
Mikkel Kjeldsen created MCOMPILER-572:
-
Summary: Multi-line does not work on Windows when forked
Key: MCOMPILER-572
URL: https://issues.apache.org/jira/browse/MCOMPILER-572
Project: Maven Compiler Plugin
Issue Type: Bug
Affects Versions: 3.12.1
Reporter: Mikkel Kjeldsen
Versions of {{maven-compiler-plugin}} that rely on {{plexus-compiler-2.14.2}},
hereunder {{maven-compiler-plugin-3.12.1}}, cannot pass multi-line compiler
arguments to a forked {{javac}} on Windows in any way. Further, attempting to
do so produces a non-obvious and difficult to troubleshoot error. This error
does not manifest outside of Windows, nor does it manifest on Windows if the
compiler is not forked.
This bug is a downstream version of
https://github.com/codehaus-plexus/plexus-compiler/issues/351 (Forking
JavacCompiler breaks multiline arguments on Windows).
The sample POM
{code:xml}
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0
example.multi-line-fork-crash
minimally-reproducible
1.0-SNAPSHOT
21
3.12.1
org.apache.maven.plugins
maven-compiler-plugin
${maven-compiler-plugin.version}
true
-Xplugin:ErrorProne \
-Xep:DeadException:WARN
{code}
_should_ fail to compile with the error
{noformat}
plug-in not found: ErrorProne
{noformat}
but instead fails with the error
{noformat}
error: invalid flag: -Xep:DeadException
{noformat}
because {{plexus-compiler}} indiscriminately translates the \ to / and breaks
{{javac}} 's multi-line argument support.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikkel Kjeldsen updated MINVOKER-351:
-
Description:
Neither the Maven Invoker plugin's implementation of {{}} nor
the underlying XML infrastructure directly protect against the presence of
character literals prohibited by the XML specification, meaning such literals
can appear in the JUnit report and render it unreadable. *I would appreciate if
the Maven Invoker plugin could learn to strip prohibited literals to protect
its users from creative plugins.* I argue that this is a safe and expected
transformation that is not materially lossy.
h2. Background
MINVOKER-196 added the {{}} option [back in
maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
report remains effectively
unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
The JUnit report includes a {{}} element ([example
documentation|https://github.com/testmoapp/junitxml]) whose value Maven Invoker
populates with the raw build log contents. I've observed that this value is
XML-escaped, which I imagine is well understood in the implementation, although
I can't immediately find documentation to support that.
However, escaping notwithstanding, a number of character literals are outright
prohibited by the XML specifications. These literals cannot be escaped, and
their presence renders an XML document not well formed. The exact set of
prohibited characters varies by XML version; the report produced by the Maven
Invoker plugin is XML version 1.0. When the Maven Invoker plugin reads in the
build log it does not strip these character literals and neither does the XML
writer the Maven Invoker plugin relies on. Consequently, if a build log ends up
including a prohibited character the resulting JUnit report will not be well
formed.
The set of prohibited characters is the complement of [the XML specification's
definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
h2. Example
Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
[pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
spinner to standard out, and the implementation uses backspace to render the
spinner in place. I have used the Maven Invoker plugin with
{{}} to verify a pitest configuration, whereby I discovered
this limitation.
h2. Remediation
h3. Blame plugins
Perhaps pitest should not behave this way but we can't change pitest, and even
if pitest could be changed that offers no protection against any other plugin,
so blaming plugins is an ineffective course of action.
h3. Work-arounds
The user can manually clean the build log in-place via
{{}}. This is technically fairly easy to do, and makes the
transformation very explicit, but it requires considerable local work to
address an issue many would find obscure and the transformation is permanently
lossy unless the user also backs up the raw log to another file name.
h3. Strip prohibited literals inside Maven Invoker plugin
If the Maven Invoker plugin learns to strip offending character literals
in-between reading the build log and writing to the {{}} value then
{{}} will Just Work™, which I assert is what a user will
typically expect. Although the {{}} value will no longer exactly
match the build log contents, this lossy translation is acceptable: the
prohibited characters are overwhelmingly unprintable to begin with and
therefore cannot be meaningfully rendered in a static context, and the raw
build log remains unchanged in the event that the user needs to investigate or
assert against the raw output.
This change would be backwards compatible, because any existing user that would
be affected by it would already have unparseable JUnit reports.
* I _believe_ that Java's {{j.u.r.Pattern}} can trivially express the
complement of allowed characters but there may exist more efficient solutions.
* Consider also applying this transformation to the 2 uses of
{{buildJob.getFailureMessage()}}.
h4. Replace prohibited literals inside Maven Invoker plugin
As a variation of stripping prohibited character literals, the Maven Invoker
plugin could substitute sentinel values for prohibited character literals. This
approach has the downside that it requires additional decision making for
determining suitable substitution(s) but is otherwise comparable.
was:
Neither the Maven Invoker plugin's implementation of {{}} nor
the underlying XML infrastructure directly protect against the presence of
character literals prohibited by the XML
[jira] [Updated] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikkel Kjeldsen updated MINVOKER-351:
-
Description:
Neither the Maven Invoker plugin's implementation of {{}} nor
the underlying XML infrastructure directly protect against the presence of
character literals prohibited by the XML specification, meaning such literals
can appear in the JUnit report and render it unreadable. *I would appreciate if
the Maven Invoker plugin could learn to strip prohibited literals to protect
its users from creative plugins.* I argue that this is a safe and expected
transformation that is not materially lossy.
h2. Background
MINVOKER-196 added the {{}} option [back in
maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
report remains effectively
unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
The JUnit report includes a {{}} element ([example
documentation|https://github.com/testmoapp/junitxml]) whose value Maven Invoker
populates with the raw build log contents. I've observed that this value is
XML-escaped, which I imagine is well understood in the implementation, although
I can't immediately find documentation to support that.
However, escaping notwithstanding, a number of character literals are outright
prohibited by the XML specifications. These literals cannot be escaped, and
their presence renders an XML document not well formed. The exact set of
prohibited characters varies by XML version; the report produced by the Maven
Invoker plugin is XML version 1.0. When the Maven Invoker plugin reads in the
build log it does not strip these character literals and neither does the XML
writer the Maven Invoker plugin relies on. Consequently, if a build log ends up
including a prohibited character the resulting JUnit report will not be well
formed.
The set of prohibited characters is the complement of [the XML specification's
definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
h2. Example
Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
[pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
spinner to standard out, and the implementation uses backspace to render the
spinner in place. I have used the Maven Invoker plugin with
{{}} to verify a pitest configuration, whereby I discovered
this limitation.
h2. Remediation
h3. Blame plugins
Perhaps pitest should not behave this way but we can't change pitest, and even
if pitest could be changed that offers no protection against any other plugin,
so blaming plugins is an ineffective course of action.
h3. Work-arounds
The user can manually clean the build log in-place via
{{}}. This is technically fairly easy to do, and makes the
transformation very explicit, but it requires considerable local work to
address an issue many would find obscure and the transformation is permanently
lossy unless the user also backs up the raw log to another file name.
h3. Strip prohibited literals inside Maven Invoker plugin
If the Maven Invoker plugin learns to strip offending character literals
in-between reading the build log and writing to the {{}} value then
{{}} will Just Work™, which I assert is what a user will
typically expect. Although the {{}} value will no longer exactly
match the build log contents, this lossy translation is acceptable: the
prohibited characters are overwhelmingly unprintable to begin with and
therefore cannot be meaningfully rendered in a static context, and the raw
build log remains unchanged in the event that the user needs to investigate or
assert against the raw output.
This change would be backwards compatible, because any existing user that would
be affected by it would already have unparseable JUnit reports.
I _believe_ that Java's {{j.u.r.Pattern}} can trivially express the complement
of allowed characters but there may exist more efficient solutions.
h4. Replace prohibited literals inside Maven Invoker plugin
As a variation of stripping prohibited character literals, the Maven Invoker
plugin could substitute sentinel values for prohibited character literals. This
approach has the downside that it requires additional decision making for
determining suitable substitution(s) but is otherwise comparable.
was:
Neither the Maven Invoker plugin's implementation of {{}} nor
the underlying XML infrastructure directly protect against the presence of
character literals prohibited by the XML specification, meaning such literals
can appear in the JUnit report and render it unreadable. *I would
[jira] [Updated] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikkel Kjeldsen updated MINVOKER-351:
-
Description:
Neither the Maven Invoker plugin's implementation of {{}} nor
the underlying XML infrastructure directly protect against the presence of
character literals prohibited by the XML specification, meaning such literals
can appear in the JUnit report and render it unreadable. *I would appreciate if
the Maven Invoker plugin could learn to strip prohibited literals to protect
its users from creative plugins.* I argue that this is a safe and expected
transformation that is not materially lossy.
h2. Background
MINVOKER-196 added the {{}} option [back in
maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
report remains effectively
unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
The JUnit report includes a {{}} element ([example
documentation|https://github.com/testmoapp/junitxml]) whose value Maven Invoker
populates with the raw build log contents. I've observed that this value is
XML-escaped, which I imagine is well understood in the implementation, although
I can't immediately find documentation to support that.
However, escaping notwithstanding, a number of character literals are outright
prohibited by the XML specifications. These literals cannot be escaped, and
their presence renders an XML document not well formed. The exact set of
prohibited characters varies by XML version; the report produced by the Maven
Invoker plugin is XML version 1.0. When the Maven Invoker plugin reads in the
build log it does not strip these character literals and neither does the XML
writer the Maven Invoker plugin relies on. Consequently, if a build log ends up
including a prohibited character the resulting JUnit report will not be well
formed.
The set of prohibited characters is the complement of [the XML specification's
definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
h2. Example
Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
[pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
spinner to standard out, and the implementation uses backspace to render the
spinner in place. I have used the Maven Invoker plugin with
{{}} to verify a pitest configuration, whereby I discovered
this limitation.
h2. Remediation
h3. Blame plugins
Perhaps pitest should not behave this way but we can't change pitest, and even
if pitest could be changed that offers no protection against any other plugin,
so blaming plugins is an ineffective course of action.
h3. Work-arounds
The user can manually clean the build log in-place via
{{}}. This is technically fairly easy to do, and makes the
transformation very explicit, but it requires considerable local work to
address an issue many would find obscure and the transformation is permanently
lossy unless the user also backs up the raw log to another file name.
h3. Strip prohibited literals inside Maven Invoker plugin
If the Maven Invoker plugin learns to strip offending character literals
in-between reading the build log and writing to the {{}} value then
{{}} will Just Work™, which I assert is what a user will
typically expect. Although the {{}} value will no longer exactly
match the build log contents, this lossy translation is acceptable: the
prohibited characters are overwhelmingly unprintable to begin with and
therefore cannot be meaningfully rendered in a static context, and the raw
build log remains unchanged in the event that the user needs to investigate or
assert against the raw output.
This change would be backwards compatible, because any existing user that would
be affected by it would already have unparseable JUnit reports.
I _believe_ that Java's {{Pattern}} can trivially express the complement of
allowed characters but there may exist more efficient solutions.
h4. Replace prohibited literals inside Maven Invoker plugin
As a variation of stripping prohibited character literals, the Maven Invoker
plugin could substitute sentinel values for prohibited character literals. This
approach has the downside that it requires additional decision making for
determining suitable substitution(s) but is otherwise comparable.
was:
Neither the Maven Invoker plugin's implementation of {{}} nor
the underlying XML infrastructure directly protect against the presence of
character literals prohibited by the XML specification, meaning such literals
can appear in the JUnit report and render it unreadable. *I would appreciate if
[jira] [Updated] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikkel Kjeldsen updated MINVOKER-351:
-
Description:
Neither the Maven Invoker plugin's implementation of {{}} nor
the underlying XML infrastructure directly protect against the presence of
character literals prohibited by the XML specification, meaning such literals
can appear in the JUnit report and render it unreadable. *I would appreciate if
the Maven Invoker plugin could learn to strip prohibited literals to protect
its users from creative plugins.* I argue that this is a safe and expected
transformation that is not materially lossy.
h2. Background
MINVOKER-196 added the {{}} option [back in
maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
report remains effectively
unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
The JUnit report includes a {{}} element ([example
documentation|https://github.com/testmoapp/junitxml]) whose value Maven Invoker
populates with the raw build log contents. I've observed that this value is
XML-escaped, which I imagine is well understood in the implementation, although
I can't immediately find documentation to support that.
However, escaping notwithstanding, a number of character literals are outright
prohibited by the XML specifications. These literals cannot be escaped, and
their presence renders an XML document not well formed. The exact set of
prohibited characters varies by XML version; the report produced by the Maven
Invoker plugin is XML version 1.0. When the Maven Invoker plugin reads in the
build log it does not strip these character literals and neither does the XML
writer the Maven Invoker plugin relies on. Consequently, if a build log ends up
including a prohibited character the resulting JUnit report will not be well
formed.
h2. Example
Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
[pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
spinner to standard out, and the implementation uses backspace to render the
spinner in place. I have used the Maven Invoker plugin with
{{}} to verify a pitest configuration, whereby I discovered
this limitation.
h2. Remediation
h3. Blame plugins
Perhaps pitest should not behave this way but we can't change pitest, and even
if pitest could be changed that offers no protection against any other plugin,
so blaming plugins is an ineffective course of action.
h3. Work-arounds
The user can manually clean the build log in-place via
{{}}. This is technically fairly easy to do, and makes the
transformation very explicit, but it requires considerable local work to
address an issue many would find obscure and the transformation is permanently
lossy unless the user also backs up the raw log to another file name.
h3. Strip prohibited literals inside Maven Invoker plugin
If the Maven Invoker plugin learns to strip offending character literals
in-between reading the build log and writing to the {{}} value then
{{}} will Just Work™, which I assert is what a user will
typically expect. Although the {{}} value will no longer exactly
match the build log contents, this lossy translation is acceptable: the
prohibited characters are overwhelmingly unprintable to begin with and
therefore cannot be meaningfully rendered in a static context, and the raw
build log remains unchanged in the event that the user needs to investigate or
assert against the raw output.
This change would be backwards compatible, because any existing user that would
be affected by it would already have unparseable JUnit reports.
h4. Replace prohibited literals inside Maven Invoker plugin
As a variation of stripping prohibited character literals, the Maven Invoker
plugin could substitute sentinel values for prohibited character literals. This
approach has the downside that it requires additional decision making for
determining suitable substitution(s) but is otherwise comparable.
was:
Neither the Maven Invoker plugin's implementation of {{}} nor
the underlying XML infrastructure directly protect against the presence of
character literals prohibited by the XML specification, meaning such literals
can appear in the JUnit report and render it unreadable. I would appreciate if
the Maven Invoker plugin could learn to strip such literals to protect its
users from creative plugins. I argue that this is a safe and expected
transformation that is not materially lossy.
h2. Background
MINVOKER-196 added the {{}} option [back in
[jira] [Updated] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikkel Kjeldsen updated MINVOKER-351:
-
Description:
Neither the Maven Invoker plugin's implementation of {{}} nor
the underlying XML infrastructure directly protect against the presence of
character literals prohibited by the XML specification, meaning such literals
can appear in the JUnit report and render it unreadable. I would appreciate if
the Maven Invoker plugin could learn to strip such literals to protect its
users from creative plugins. I argue that this is a safe and expected
transformation that is not materially lossy.
h2. Background
MINVOKER-196 added the {{}} option [back in
maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
report remains effectively
unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
The JUnit report includes a {{}} element ([example
documentation|https://github.com/testmoapp/junitxml]) whose value Maven Invoker
populates with the raw build log contents. I've observed that this value is
XML-escaped, which I imagine is well understood in the implementation, although
I can't immediately find documentation to support that.
However, escaping notwithstanding, a number of character literals are outright
prohibited by the XML specifications. These literals cannot be escaped, and
their presence renders an XML document not well formed. The exact set of
prohibited characters varies by XML version; the report produced by the Maven
Invoker plugin is XML version 1.0. When the Maven Invoker plugin reads in the
build log it does not strip these character literals and neither does the XML
writer the Maven Invoker plugin relies on. Consequently, if a build log ends up
including a prohibited character the resulting JUnit report will not be well
formed.
h2. Example
Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
[pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
spinner to standard out, and the implementation uses backspace to render the
spinner in place. I have used the Maven Invoker plugin with
{{}} to verify a pitest configuration, whereby I discovered
this limitation.
h2. Remediation
h3. Blame plugins
Perhaps pitest should not behave this way but we can't change pitest, and even
if pitest could be changed that offers no protection against any other plugin,
so blaming plugins is an ineffective course of action.
h3. Work-arounds
The user can manually clean the build log in-place via
{{}}. This is technically fairly easy to do, and makes the
transformation very explicit, but it requires considerable local work to
address an issue many would find obscure and the transformation is permanently
lossy unless the user also backs up the raw log to another file name.
h3. Strip prohibited literals inside Maven Invoker plugin
If the Maven Invoker plugin learns to strip offending character literals
in-between reading the build log and writing to the {{}} value then
{{}} will Just Work™, which I assert is what a user will
typically expect. Although the {{}} value will no longer exactly
match the build log contents, this lossy translation is acceptable: the
prohibited characters are overwhelmingly unprintable to begin with and
therefore cannot be meaningfully rendered in a static context, and the raw
build log remains unchanged in the event that the user needs to investigate or
assert against the raw output.
This change would be backwards compatible, because any existing user that would
be affected by it would already have unparseable JUnit reports.
h4. Replace prohibited literals inside Maven Invoker plugin
As a variation of stripping prohibited character literals, the Maven Invoker
plugin could substitute sentinel values for prohibited character literals. This
approach has the downside that it requires additional decision making for
determining suitable substitution(s) but is otherwise comparable.
was:
Neither Maven Invoker's implementation of {{}} nor the
underlying XML infrastructure directly protect against the presence of
character literals prohibited by the XML specification, meaning such literals
can appear in the JUnit report and render it unreadable. I would appreciate if
Maven Invoker could learn to strip such literals to protect its users from
creative plugins. I argue that this is a safe and expected transformation
despite also being lossy.
h2. Background
MINVOKER-196 added the {{}} option [back in
[jira] [Updated] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikkel Kjeldsen updated MINVOKER-351:
-
Description:
Neither Maven Invoker's implementation of {{}} nor the
underlying XML infrastructure directly protect against the presence of
character literals prohibited by the XML specification, meaning such literals
can appear in the JUnit report and render it unreadable. I would appreciate if
Maven Invoker could learn to strip such literals to protect its users from
creative plugins. I argue that this is a safe and expected transformation
despite also being lossy.
h2. Background
MINVOKER-196 added the {{}} option [back in
maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
report remains effectively
unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
The JUnit report includes a {{}} element ([example
documentation|https://github.com/testmoapp/junitxml]) whose value Maven Invoker
populates with the raw build log contents. I've observed that this value is
XML-escaped, which I imagine is well understood in the implementation, although
I can't immediately find documentation to support that.
However, escaping notwithstanding, a number of character literals are outright
prohibited by the XML specifications. These literals cannot be escaped, and
their presence renders an XML document not well formed. The exact set of
prohibited characters varies by XML version; the report produced by Maven
Invoker is XML version 1.0. When Maven Invoker reads in the build log it does
not strip these character literals and neither does the XML writer Maven
Invoker relies on. Consequently, if a build log ends up including a prohibited
character the resulting JUnit report will not be well formed.
h2. Example
Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
[pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
spinner to standard out, and the implementation uses backspace to render the
spinner in place.
Perhaps pitest should not behave this way but we can't change pitest, and even
if pitest could be changed that offers no protection against any other plugin,
so blaming plugins is an ineffective argument.
was:
Neither Maven Invoker's implementation of {{}} nor the
underlying XML infrastructure directly protect against the presence of
character literals prohibited by the XML specification, meaning such literals
can appear in the JUnit report and render it unreadable. I would appreciate if
Maven Invoker could learn to strip such literals to protect its users from
creative plugins. I argue that this is a safe and expected transformation
despite also being lossy.
MINVOKER-196 added the {{}} option [back in
maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
report remains effectively
unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
The JUnit report includes a {{}} element ([example
documentation|https://github.com/testmoapp/junitxml]) whose value Maven Invoker
populates with the raw build log contents. I've observed that this value is
XML-escaped, which I imagine is well understood in the implementation, although
I can't immediately find documentation to support that.
However, escaping notwithstanding, a number of character literals are outright
prohibited by the XML specifications. These literals cannot be escaped, and
their presence renders an XML document not well formed. The exact set of
prohibited characters varies by XML version; the report produced by Maven
Invoker is XML version 1.0. When Maven Invoker reads in the build log it does
not strip these character literals and neither does the XML writer Maven
Invoker relies on. Consequently, if a build log ends up including a prohibited
character the resulting JUnit report will not be well formed.
h2. Example
Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
[pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
spinner to standard out, and the implementation uses backspace to render the
spinner in place.
Perhaps pitest should not behave this way but we can't change pitest, and even
if pitest could be changed that offers no protection
[jira] [Updated] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikkel Kjeldsen updated MINVOKER-351:
-
Description:
Neither Maven Invoker's implementation of {{}} nor the
underlying XML infrastructure directly protect against the presence of
character literals prohibited by the XML specification, meaning such literals
can appear in the JUnit report and render it unreadable. I would appreciate if
Maven Invoker could learn to strip such literals to protect its users from
creative plugins. I argue that this is a safe and expected transformation
despite also being lossy.
MINVOKER-196 added the {{}} option [back in
maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
report remains effectively
unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
The JUnit report includes a {{}} element ([example
documentation|https://github.com/testmoapp/junitxml]) whose value Maven Invoker
populates with the raw build log contents. I've observed that this value is
XML-escaped, which I imagine is well understood in the implementation, although
I can't immediately find documentation to support that.
However, escaping notwithstanding, a number of character literals are outright
prohibited by the XML specifications. These literals cannot be escaped, and
their presence renders an XML document not well formed. The exact set of
prohibited characters varies by XML version; the report produced by Maven
Invoker is XML version 1.0. When Maven Invoker reads in the build log it does
not strip these character literals and neither does the XML writer Maven
Invoker relies on. Consequently, if a build log ends up including a prohibited
character the resulting JUnit report will not be well formed.
h2. Example
Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
[pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
spinner to standard out, and the implementation uses backspace to render the
spinner in place.
Perhaps pitest should not behave this way but we can't change pitest, and even
if pitest could be changed that offers no protection against any other plugin,
so blaming plugins is an ineffective argument.
was:
Neither Maven Invoker's implementation of {{}} nor the
underlying XML infrastructure directly protect against the presence of
character literals prohibited by the XML specification, meaning such literals
can appear in the JUnit report and render it unreadable. I would appreciate if
Maven Invoker could learn to strip such literals to protect its users from
creative plugins. I argue that this is a safe and expected transformation
despite also being lossy.
MINVOKER-196 added the {{}} option [back in
maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
report remains effectively
unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
The JUnit report includes a {{}} element ([example
documentation|https://github.com/testmoapp/junitxml]) whose value Maven Invoker
populates with the raw build log contents. I've observed that this value is
XML-escaped, which I imagine is well understood in the implementation, although
I can't immediately find documentation to support that.
However, escaping notwithstanding, a number of character literals are outright
prohibited by the XML specifications. These literals cannot be escaped, and
their presence renders an XML document not well formed. The exact set of
prohibited characters varies by XML version; the report produced by Maven
Invoker is XML version 1.0.
Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
[pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
spinner to standard out, and the implementation uses backspace to render the
spinner in place.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Reporter: Mikkel Kjeldsen
>Priority: Major
>
> Neither Maven Invoker's implementation of
[jira] [Updated] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikkel Kjeldsen updated MINVOKER-351:
-
Description:
Neither Maven Invoker's implementation of {{}} nor the
underlying XML infrastructure directly protect against the presence of
character literals prohibited by the XML specification, meaning such literals
can appear in the JUnit report and render it unreadable. I would appreciate if
Maven Invoker could learn to strip such literals to protect its users from
creative plugins. I argue that this is a safe and expected transformation
despite also being lossy.
MINVOKER-196 added the {{}} option [back in
maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
report remains effectively
unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
The JUnit report includes a {{}} element ([example
documentation|https://github.com/testmoapp/junitxml]) whose value Maven Invoker
populates with the raw build log contents. I've observed that this value is
XML-escaped, which I imagine is well understood in the implementation, although
I can't immediately find documentation to support that.
However, escaping notwithstanding, a number of character literals are outright
prohibited by the XML specifications. These literals cannot be escaped, and
their presence renders an XML document not well formed. The exact set of
prohibited characters varies by XML version; the report produced by Maven
Invoker is XML version 1.0.
Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
[pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
spinner to standard out, and the implementation uses backspace to render the
spinner in place.
was:
MINVOKER-196 added the {{}} option [back in
maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
report remains effectively
unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Reporter: Mikkel Kjeldsen
>Priority: Major
>
> Neither Maven Invoker's implementation of {{}} nor the
> underlying XML infrastructure directly protect against the presence of
> character literals prohibited by the XML specification, meaning such literals
> can appear in the JUnit report and render it unreadable. I would appreciate
> if Maven Invoker could learn to strip such literals to protect its users from
> creative plugins. I argue that this is a safe and expected transformation
> despite also being lossy.
>
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by Maven Invoker is XML version 1.0.
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses
[jira] [Updated] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikkel Kjeldsen updated MINVOKER-351:
-
Description:
MINVOKER-196 added the {{}} option [back in
maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
report remains effectively
unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
was:
MINVOKER-196 added the {{}} option [back in
maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
[In maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
report remains
unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754]
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Reporter: Mikkel Kjeldsen
>Priority: Major
>
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikkel Kjeldsen updated MINVOKER-351:
-
Description:
MINVOKER-196 added the {{}} option [back in
maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
[In maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
report remains
unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754]
was:
MINVOKER-196 added the {{}} option back in
maven-invoker-plugin-3.2.1. [In maven-invoker-plugin-3.6.0 the effective
implementation of the JUnit report remains
unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754]
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Reporter: Mikkel Kjeldsen
>Priority: Major
>
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> [In maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikkel Kjeldsen updated MINVOKER-351:
-
Description:
MINVOKER-196 added the {{}} option back in
maven-invoker-plugin-3.2.1. [In maven-invoker-plugin-3.6.0 the effective
implementation of the JUnit report remains
unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754]
was:MINVOKER-196 added the {{}} option back in v3.2.1.
Since then the effective implementation of the JUnit report has not changed.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Reporter: Mikkel Kjeldsen
>Priority: Major
>
> MINVOKER-196 added the {{}} option back in
> maven-invoker-plugin-3.2.1. [In maven-invoker-plugin-3.6.0 the effective
> implementation of the JUnit report remains
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikkel Kjeldsen updated MINVOKER-351:
-
Summary: Prevent XML-prohibited characters from entering JUnit report
(was: Prevent XML-disallowed characters from entering JUnit report)
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Reporter: Mikkel Kjeldsen
>Priority: Major
>
> MINVOKER-196 added the {{}} option back in v3.2.1. Since
> then the effective implementation of the JUnit report has not changed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MINVOKER-351) Prevent XML-disallowed characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikkel Kjeldsen updated MINVOKER-351:
-
Description: MINVOKER-196 added the {{}} option back in
v3.2.1. Since then the effective implementation of the JUnit report has not
changed.
> Prevent XML-disallowed characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Reporter: Mikkel Kjeldsen
>Priority: Major
>
> MINVOKER-196 added the {{}} option back in v3.2.1. Since
> then the effective implementation of the JUnit report has not changed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MINVOKER-351) Prevent XML-disallowed characters from entering JUnit report
[ https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikkel Kjeldsen updated MINVOKER-351: - Summary: Prevent XML-disallowed characters from entering JUnit report (was: JUnit) > Prevent XML-disallowed characters from entering JUnit report > > > Key: MINVOKER-351 > URL: https://issues.apache.org/jira/browse/MINVOKER-351 > Project: Maven Invoker Plugin > Issue Type: Improvement >Reporter: Mikkel Kjeldsen >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MINVOKER-351) JUnit
Mikkel Kjeldsen created MINVOKER-351: Summary: JUnit Key: MINVOKER-351 URL: https://issues.apache.org/jira/browse/MINVOKER-351 Project: Maven Invoker Plugin Issue Type: Improvement Reporter: Mikkel Kjeldsen -- This message was sent by Atlassian Jira (v8.20.10#820010)
