[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=17847608#comment-17847608
]
ASF GitHub Bot commented on MINVOKER-351:
-
elharo commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2119020002
I guess it depends on what it means when a NUL character or other C0 control
appears here. It might be fine to drop them or replace each one with a space,
especially if you don't care about round triipping.
> 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 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
Re: [PR] [MINVOKER-351] Escape special xml character in junit report [maven-invoker-plugin]
elharo commented on PR #242: URL: https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2119020002 I guess it depends on what it means when a NUL character or other C0 control appears here. It might be fine to drop them or replace each one with a space, especially if you don't care about round triipping. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MINVOKER-351] Escape special xml character in junit report [maven-invoker-plugin]
michael-o commented on PR #242: URL: https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2119019388 > > output: > > ``` > > Exception in thread "main" java.lang.IllegalStateException: character 0 is not allowed in output > > at org.codehaus.plexus.util.xml.pull.MXSerializer.writeElementContent(MXSerializer.java:947) > > at org.codehaus.plexus.util.xml.pull.MXSerializer.text(MXSerializer.java:780) > > at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.main(DefaultSiteRenderer.java:955) > > ``` > > . Character 0, i,e. ASCII NUL, and a few others are deeply problematic as they can neither be included in XML documents nor escaped. If you're really trying to wrap arbitrary binary data into XML then you have to Base 64 encode it, though in this case we shouldn't be seeing those characters in the strings. > > Otherwise you need some sort of application specific convention for how you'll encode the disallowed C0 controls. E.g. writing each one as an element like ` or something like that. However you need to come up with that yourself. The XML parser/serializer won't help you there. ` In our case the easiest way would be to drop them, no? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[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=17847607#comment-17847607
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2119019388
> > output:
> > ```
> > Exception in thread "main" java.lang.IllegalStateException: character 0
is not allowed in output
> > at
org.codehaus.plexus.util.xml.pull.MXSerializer.writeElementContent(MXSerializer.java:947)
> > at
org.codehaus.plexus.util.xml.pull.MXSerializer.text(MXSerializer.java:780)
> > at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.main(DefaultSiteRenderer.java:955)
> > ```
>
> . Character 0, i,e. ASCII NUL, and a few others are deeply problematic as
they can neither be included in XML documents nor escaped. If you're really
trying to wrap arbitrary binary data into XML then you have to Base 64 encode
it, though in this case we shouldn't be seeing those characters in the strings.
>
> Otherwise you need some sort of application specific convention for how
you'll encode the disallowed C0 controls. E.g. writing each one as an element
like ` or something like that. However you need to come up with
that yourself. The XML parser/serializer won't help you there. `
In our case the easiest way would be to drop them, no?
> 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 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
[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=17847605#comment-17847605
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on code in PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#discussion_r1605818675
##
src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java:
##
@@ -1640,7 +1642,7 @@ private void runBuild(
}
} catch (RunFailureException e) {
buildJob.setResult(e.getType());
-buildJob.setFailureMessage(e.getMessage());
+
buildJob.setFailureMessage(StringEscapeUtils.escapeXml10(e.getMessage()));
Review Comment:
> Assuming buildJob is just an object that contains strings and other
things, but has no particular XML internals (like 99.9% of classes that contain
strings) nothing inside it should be escaped.
>
> Ideally the XML writer should escape strings when it needs to. Or if the
XML writer is broken and won't do that, then the escaping should be done after
the string is extracted from the buildJob and before it's passed to the writer.
Escaping strings inside the buildJob breaks its semantics and tightly couples
all the classes together in one particularly brittle path.
Yes, the XML writer is broken and needs an issue.
> 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 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
Re: [PR] [MINVOKER-351] Escape special xml character in junit report [maven-invoker-plugin]
michael-o commented on code in PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#discussion_r1605818675
##
src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java:
##
@@ -1640,7 +1642,7 @@ private void runBuild(
}
} catch (RunFailureException e) {
buildJob.setResult(e.getType());
-buildJob.setFailureMessage(e.getMessage());
+
buildJob.setFailureMessage(StringEscapeUtils.escapeXml10(e.getMessage()));
Review Comment:
> Assuming buildJob is just an object that contains strings and other
things, but has no particular XML internals (like 99.9% of classes that contain
strings) nothing inside it should be escaped.
>
> Ideally the XML writer should escape strings when it needs to. Or if the
XML writer is broken and won't do that, then the escaping should be done after
the string is extracted from the buildJob and before it's passed to the writer.
Escaping strings inside the buildJob breaks its semantics and tightly couples
all the classes together in one particularly brittle path.
Yes, the XML writer is broken and needs an issue.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[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=17847604#comment-17847604
]
ASF GitHub Bot commented on MINVOKER-351:
-
elharo commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2119018051
> output:
>
> ```
> Exception in thread "main" java.lang.IllegalStateException: character 0 is
not allowed in output
>at
org.codehaus.plexus.util.xml.pull.MXSerializer.writeElementContent(MXSerializer.java:947)
>at
org.codehaus.plexus.util.xml.pull.MXSerializer.text(MXSerializer.java:780)
>at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.main(DefaultSiteRenderer.java:955)
> ```
.
Character 0, i,e. ASCII NUL, and a few others are deeply problematic as they
can neither be included in XML documents nor escaped. If you're really trying
to wrap arbitrary binary data into XML then you have to Base 64 encode it,
though in this case we shouldn't be seeing those characters in the strings.
Otherwise you need some sort of application specific convention for how
you'll encode the disallowed C0 controls. E.g. writing each one as an element
like ` or something like that. However you need to come up with
that yourself. The XML parser/serializer won't help you there. `
> 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 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
Re: [PR] [MINVOKER-351] Escape special xml character in junit report [maven-invoker-plugin]
elharo commented on PR #242: URL: https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2119018051 > output: > > ``` > Exception in thread "main" java.lang.IllegalStateException: character 0 is not allowed in output >at org.codehaus.plexus.util.xml.pull.MXSerializer.writeElementContent(MXSerializer.java:947) >at org.codehaus.plexus.util.xml.pull.MXSerializer.text(MXSerializer.java:780) >at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.main(DefaultSiteRenderer.java:955) > ``` . Character 0, i,e. ASCII NUL, and a few others are deeply problematic as they can neither be included in XML documents nor escaped. If you're really trying to wrap arbitrary binary data into XML then you have to Base 64 encode it, though in this case we shouldn't be seeing those characters in the strings. Otherwise you need some sort of application specific convention for how you'll encode the disallowed C0 controls. E.g. writing each one as an element like ` or something like that. However you need to come up with that yourself. The XML parser/serializer won't help you there. ` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MSHARED-1398) StringIndexOutOfBoundsException processing record classes
[
https://issues.apache.org/jira/browse/MSHARED-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847603#comment-17847603
]
Jared Stehler commented on MSHARED-1398:
confirmed that fixed my original issue.
> StringIndexOutOfBoundsException processing record classes
> -
>
> Key: MSHARED-1398
> URL: https://issues.apache.org/jira/browse/MSHARED-1398
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.14.0
>Reporter: Jared Stehler
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: maven-dependency-analyzer-next-release
>
>
> Processing classes with records results in an index out of bounds exception:
> {code:java}
> Caused by: java.lang.StringIndexOutOfBoundsException: Index 41 out of bounds
> for length 41
> at
> java.base@21.0.3/jdk.internal.util.Preconditions$1.apply(Preconditions.java:55)
> at
> java.base@21.0.3/jdk.internal.util.Preconditions$1.apply(Preconditions.java:52)
> at
> java.base@21.0.3/jdk.internal.util.Preconditions$4.apply(Preconditions.java:213)
> at
> java.base@21.0.3/jdk.internal.util.Preconditions$4.apply(Preconditions.java:210)
> at
> java.base@21.0.3/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:98)
> at
> java.base@21.0.3/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
> at
> java.base@21.0.3/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
> at java.base@21.0.3/java.lang.String.checkIndex(String.java:4832)
> at java.base@21.0.3/java.lang.StringLatin1.charAt(StringLatin1.java:46)
> at java.base@21.0.3/java.lang.String.charAt(String.java:1555)
> at app//org.objectweb.asm.Type.getReturnTypeOffset(Type.java:378)
> at app//org.objectweb.asm.Type.getReturnType(Type.java:355)
> at
> app//org.apache.maven.shared.dependency.analyzer.asm.ResultCollector.addMethodDesc(ResultCollector.java:112)
> {code}
> I have a reproducible test case here:
> https://github.com/jaredstehler/maven-dependency-analyzer/tree/js-repro-record-error
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[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=17847594#comment-17847594
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118995261
And the value is indeed correct:
```java
Document doc2 =
DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(new
ByteArrayInputStream(w.toString().getBytes(StandardCharsets.UTF_8)));
NodeList childNodes = doc2.getDocumentElement().getChildNodes();
for (int i = 0; i < childNodes.getLength(); i++) {
System.out.println(childNodes.item(i).getTextContent());
}
```
output:
[Fatal Error] :3:19: Zeichenreferenz
Re: [PR] [MINVOKER-351] Escape special xml character in junit report [maven-invoker-plugin]
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118995261
And the value is indeed correct:
```java
Document doc2 =
DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(new
ByteArrayInputStream(w.toString().getBytes(StandardCharsets.UTF_8)));
NodeList childNodes = doc2.getDocumentElement().getChildNodes();
for (int i = 0; i < childNodes.getLength(); i++) {
System.out.println(childNodes.item(i).getTextContent());
}
```
output:
[Fatal Error] :3:19: Zeichenreferenz
[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=17847593#comment-17847593
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118994193
I have now tested the IT with the patched Plexus XML. Output looks fine now:
```
[INFO] Running example.minvoker351.ExampleTest
- name: NULL
- name: START OF HEADING
- name: START OF TEXT
- name: END OF TEXT
- name: END OF TRANSMISSION
- name: ENQUIRY
- name: ACKNOWLEDGE
- name: BELL
- name: BACKSPACE
- name: CHARACTER TABULATION
- name: LINE FEED (LF)
- name: LINE TABULATION
- name: FORM FEED (FF)
- name: CARRIAGE RETURN (CR)
- name: SHIFT OUT
- name: SHIFT IN
- name: DATA LINK ESCAPE
- name: DEVICE CONTROL ONE
- name: DEVICE CONTROL TWO
- name: DEVICE CONTROL THREE
- name: DEVICE CONTROL FOUR
- name: NEGATIVE ACKNOWLEDGE
- name: SYNCHRONOUS IDLE
- name: END OF TRANSMISSION BLOCK
- name: CANCEL
- name: END OF MEDIUM
- name: SUBSTITUTE
- name: ESCAPE
- name: INFORMATION SEPARATOR FOUR
- name: INFORMATION SEPARATOR THREE
- name: INFORMATION SEPARATOR TWO
- name: INFORMATION SEPARATOR ONE
- name: SPACE
! - name: EXCLAMATION MARK
- name: QUOTATION MARK
# - name: NUMBER SIGN
$ - name: DOLLAR SIGN
% - name: PERCENT SIGN
- name: AMPERSAND
- name: APOSTROPHE
( - name: LEFT PARENTHESIS
) - name: RIGHT PARENTHESIS
* - name: ASTERISK
+ - name: PLUS SIGN
, - name: COMMA
- - name: HYPHEN-MINUS
. - name: FULL STOP
/ - name: SOLIDUS
0 - name: DIGIT ZERO
1 - name: DIGIT ONE
2 - name: DIGIT TWO
3 - name: DIGIT THREE
4 - name: DIGIT FOUR
5 - name: DIGIT FIVE
6 - name: DIGIT SIX
7 - name: DIGIT SEVEN
8 - name: DIGIT EIGHT
9 - name: DIGIT NINE
: - name: COLON
; - name: SEMICOLON
- name: LESS-THAN SIGN
= - name: EQUALS SIGN
- name: GREATER-THAN SIGN
? - name: QUESTION MARK
@ - name: COMMERCIAL AT
A - name: LATIN CAPITAL LETTER A
B - name: LATIN CAPITAL LETTER B
C - name: LATIN CAPITAL LETTER C
D - name: LATIN CAPITAL LETTER D
E - name: LATIN CAPITAL LETTER E
F - name: LATIN CAPITAL LETTER F
G - name: LATIN CAPITAL LETTER G
H - name: LATIN CAPITAL LETTER H
I - name: LATIN CAPITAL LETTER I
J - name: LATIN CAPITAL LETTER J
K - name: LATIN CAPITAL LETTER K
L - name: LATIN CAPITAL LETTER L
M - name: LATIN CAPITAL LETTER M
N - name: LATIN CAPITAL LETTER N
O - name: LATIN CAPITAL LETTER O
P - name: LATIN CAPITAL LETTER P
Q - name: LATIN CAPITAL LETTER Q
R - name: LATIN CAPITAL LETTER R
S - name: LATIN CAPITAL LETTER S
T - name: LATIN CAPITAL LETTER T
U - name: LATIN CAPITAL LETTER U
V - name: LATIN CAPITAL LETTER V
W - name: LATIN CAPITAL LETTER W
X - name: LATIN CAPITAL LETTER X
Y - name: LATIN CAPITAL LETTER Y
Z - name: LATIN CAPITAL LETTER Z
[ - name: LEFT SQUARE BRACKET
\ - name: REVERSE SOLIDUS
] - name: RIGHT SQUARE BRACKET
^ - name: CIRCUMFLEX ACCENT
_ - name: LOW LINE
` - name: GRAVE ACCENT
a - name: LATIN SMALL LETTER A
b - name: LATIN SMALL LETTER B
c - name: LATIN SMALL LETTER C
d - name: LATIN SMALL LETTER D
e - name: LATIN SMALL LETTER E
f - name: LATIN SMALL LETTER F
g - name: LATIN SMALL LETTER G
h - name: LATIN SMALL LETTER H
i - name: LATIN SMALL LETTER I
j - name: LATIN SMALL LETTER J
k - name: LATIN SMALL LETTER K
l - name: LATIN SMALL LETTER L
m - name: LATIN SMALL LETTER M
n - name: LATIN SMALL LETTER N
o - name: LATIN SMALL LETTER O
p - name: LATIN SMALL LETTER P
q - name: LATIN SMALL LETTER Q
r - name: LATIN SMALL LETTER R
s - name: LATIN SMALL LETTER S
t - name: LATIN SMALL LETTER T
u - name: LATIN SMALL LETTER U
v - name: LATIN SMALL LETTER V
w - name: LATIN SMALL LETTER W
x - name: LATIN SMALL LETTER X
y - name: LATIN SMALL LETTER Y
z - name: LATIN SMALL LETTER Z
{ - name: LEFT CURLY BRACKET
| - name: VERTICAL LINE
} - name: RIGHT CURLY BRACKET
~ - name: TILDE
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.080
s
> 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
Re: [PR] [MINVOKER-351] Escape special xml character in junit report [maven-invoker-plugin]
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118994193
I have now tested the IT with the patched Plexus XML. Output looks fine now:
```
[INFO] Running example.minvoker351.ExampleTest
- name: NULL
- name: START OF HEADING
- name: START OF TEXT
- name: END OF TEXT
- name: END OF TRANSMISSION
- name: ENQUIRY
- name: ACKNOWLEDGE
- name: BELL
- name: BACKSPACE
- name: CHARACTER TABULATION
- name: LINE FEED (LF)
- name: LINE TABULATION
- name: FORM FEED (FF)
- name: CARRIAGE RETURN (CR)
- name: SHIFT OUT
- name: SHIFT IN
- name: DATA LINK ESCAPE
- name: DEVICE CONTROL ONE
- name: DEVICE CONTROL TWO
- name: DEVICE CONTROL THREE
- name: DEVICE CONTROL FOUR
- name: NEGATIVE ACKNOWLEDGE
- name: SYNCHRONOUS IDLE
- name: END OF TRANSMISSION BLOCK
- name: CANCEL
- name: END OF MEDIUM
- name: SUBSTITUTE
- name: ESCAPE
- name: INFORMATION SEPARATOR FOUR
- name: INFORMATION SEPARATOR THREE
- name: INFORMATION SEPARATOR TWO
- name: INFORMATION SEPARATOR ONE
- name: SPACE
! - name: EXCLAMATION MARK
- name: QUOTATION MARK
# - name: NUMBER SIGN
$ - name: DOLLAR SIGN
% - name: PERCENT SIGN
- name: AMPERSAND
- name: APOSTROPHE
( - name: LEFT PARENTHESIS
) - name: RIGHT PARENTHESIS
* - name: ASTERISK
+ - name: PLUS SIGN
, - name: COMMA
- - name: HYPHEN-MINUS
. - name: FULL STOP
/ - name: SOLIDUS
0 - name: DIGIT ZERO
1 - name: DIGIT ONE
2 - name: DIGIT TWO
3 - name: DIGIT THREE
4 - name: DIGIT FOUR
5 - name: DIGIT FIVE
6 - name: DIGIT SIX
7 - name: DIGIT SEVEN
8 - name: DIGIT EIGHT
9 - name: DIGIT NINE
: - name: COLON
; - name: SEMICOLON
- name: LESS-THAN SIGN
= - name: EQUALS SIGN
- name: GREATER-THAN SIGN
? - name: QUESTION MARK
@ - name: COMMERCIAL AT
A - name: LATIN CAPITAL LETTER A
B - name: LATIN CAPITAL LETTER B
C - name: LATIN CAPITAL LETTER C
D - name: LATIN CAPITAL LETTER D
E - name: LATIN CAPITAL LETTER E
F - name: LATIN CAPITAL LETTER F
G - name: LATIN CAPITAL LETTER G
H - name: LATIN CAPITAL LETTER H
I - name: LATIN CAPITAL LETTER I
J - name: LATIN CAPITAL LETTER J
K - name: LATIN CAPITAL LETTER K
L - name: LATIN CAPITAL LETTER L
M - name: LATIN CAPITAL LETTER M
N - name: LATIN CAPITAL LETTER N
O - name: LATIN CAPITAL LETTER O
P - name: LATIN CAPITAL LETTER P
Q - name: LATIN CAPITAL LETTER Q
R - name: LATIN CAPITAL LETTER R
S - name: LATIN CAPITAL LETTER S
T - name: LATIN CAPITAL LETTER T
U - name: LATIN CAPITAL LETTER U
V - name: LATIN CAPITAL LETTER V
W - name: LATIN CAPITAL LETTER W
X - name: LATIN CAPITAL LETTER X
Y - name: LATIN CAPITAL LETTER Y
Z - name: LATIN CAPITAL LETTER Z
[ - name: LEFT SQUARE BRACKET
\ - name: REVERSE SOLIDUS
] - name: RIGHT SQUARE BRACKET
^ - name: CIRCUMFLEX ACCENT
_ - name: LOW LINE
` - name: GRAVE ACCENT
a - name: LATIN SMALL LETTER A
b - name: LATIN SMALL LETTER B
c - name: LATIN SMALL LETTER C
d - name: LATIN SMALL LETTER D
e - name: LATIN SMALL LETTER E
f - name: LATIN SMALL LETTER F
g - name: LATIN SMALL LETTER G
h - name: LATIN SMALL LETTER H
i - name: LATIN SMALL LETTER I
j - name: LATIN SMALL LETTER J
k - name: LATIN SMALL LETTER K
l - name: LATIN SMALL LETTER L
m - name: LATIN SMALL LETTER M
n - name: LATIN SMALL LETTER N
o - name: LATIN SMALL LETTER O
p - name: LATIN SMALL LETTER P
q - name: LATIN SMALL LETTER Q
r - name: LATIN SMALL LETTER R
s - name: LATIN SMALL LETTER S
t - name: LATIN SMALL LETTER T
u - name: LATIN SMALL LETTER U
v - name: LATIN SMALL LETTER V
w - name: LATIN SMALL LETTER W
x - name: LATIN SMALL LETTER X
y - name: LATIN SMALL LETTER Y
z - name: LATIN SMALL LETTER Z
{ - name: LEFT CURLY BRACKET
| - name: VERTICAL LINE
} - name: RIGHT CURLY BRACKET
~ - name: TILDE
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.080
s -- in example.minvoker351.ExampleTest
```
but the reader chokes now:
```
Caused by: org.xml.sax.SAXParseException: Character reference
[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=17847592#comment-17847592
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118989898
Naive upstream solution:
https://github.com/codehaus-plexus/plexus-xml/pull/28
> 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 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
Re: [PR] [MINVOKER-351] Escape special xml character in junit report [maven-invoker-plugin]
michael-o commented on PR #242: URL: https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118989898 Naive upstream solution: https://github.com/codehaus-plexus/plexus-xml/pull/28 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[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=17847590#comment-17847590
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118981114
With `StringEscapeUtils`:
```
NULL: START
OF HEADING: START OF TEXT: END OF TEXT:
END OF TRANSMISSION: ENQUIRY:
ACKNOWLEDGE: BELL: BACKSPACE:
CHARACTER TABULATION: LINE FEED (LF):
LINE TABULATION: FORM FEED (FF):
CARRIAGE RETURN (CR):
SHIFT OUT: SHIFT IN: DATA LINK
ESCAPE: DEVICE CONTROL ONE: DEVICE CONTROL TWO:
DEVICE CONTROL THREE: DEVICE CONTROL FOUR:
NEGATIVE ACKNOWLEDGE: SYNCHRONOUS IDLE:
END OF TRANSMISSION BLOCK: CANCEL: END
OF MEDIUM: SUBSTITUTE: ESCAPE:
INFORMATION SEPARATOR FOUR: INFORMATION SEPARATOR
THREE: INFORMATION SEPARATOR TWO: INFORMATION
SEPARATOR ONE: SPACE: EXCLAMATION MARK:
!QUOTATION MARK: quot;NUMBER SIGN:
#DOLLAR SIGN: $PERCENT SIGN: %AMPERSAND:
amp;APOSTROPHE: apos;LEFT PARENTHESIS:
(RIGHT PARENTHESIS: )ASTERISK: *PLUS
SIGN: +COMMA: ,HYPHEN-MINUS: -FULL STOP:
.SOLIDUS: /DIGIT ZERO: 0DIGIT ONE:
1DIGIT TWO: 2DIGIT THREE: 3DIGIT FOUR:
4DIGIT FIVE: 5DIGIT SIX: 6DIGIT SEVEN:
7DIGIT EIGHT: 8DIGIT NINE: 9COLON:
:SEMICOLON: ;LESS-THAN SIGN:
lt;EQUALS SIGN: =GREATER-THAN SIGN:
gt;QUESTION MARK: ?COMMERCIAL AT:
@LATIN CAPITAL LETTER A: ALATIN CAPITAL LETTER B:
BLATIN CAPITAL LETTER C: CLATIN CAPITAL LETTER D:
DLATIN CAPITAL LETTER E: ELATIN CAPITAL LETTER F:
FLATIN CAPITAL LETTER G: GLATIN CAPITAL LETTER H:
HLATIN CAPITAL LETTER I: ILATIN CAPITAL LETTER J:
JLATIN CAPITAL LETTER K: KLATIN CAPITAL LETTER L:
LLATIN CAPITAL LETTER M: MLATIN CAPITAL LETTER N:
NLATIN CAPITAL LETTER O: OLATIN CAPITAL LETTER P:
PLATIN CAPITAL LETTER Q: QLATIN CAPITAL LETTER R:
RLATIN CAPITAL LETTER S: SLATIN CAPITAL LETTER T:
TLATIN CAPITAL LETTER U: ULATIN CAPITAL LETTER V:
VLATIN CAPITAL LETTER W: WLATIN CAPITAL LETTER X:
XLATIN CAPITAL LETTER Y: YLATIN CAPITAL LETTER Z:
ZLEFT SQUARE BRACKET: [REVERSE SOLIDUS:
\RIGHT SQUARE BRACKET: ]CIRCUMFLEX ACCENT:
^LOW LINE: _GRAVE ACCENT: `LATIN SMALL
LETTER A: aLATIN SMALL LETTER B: bLATIN SMALL LETTER
C: cLATIN SMALL LETTER D: dLATIN SMALL LETTER E:
eLATIN SMALL LETTER F: fLATIN SMALL LETTER G:
gLATIN SMALL LETTER H: hLATIN SMALL LETTER I:
iLATIN SMALL LETTER J: jLATIN SMALL LETTER K:
kLATIN SMALL LETTER L: lLATIN SMALL LETTER M:
mLATIN SMALL LETTER N: nLATIN SMALL LETTER O:
oLATIN SMALL LETTER P: pLATIN SMALL LETTER Q:
qLATIN SMALL LETTER R: rLATIN SMALL LETTER S:
sLATIN SMALL LETTER T: tLATIN SMALL LETTER U:
uLATIN SMALL LETTER V: vLATIN SMALL LETTER W:
wLATIN SMALL LETTER X: xLATIN SMALL LETTER Y:
yLATIN SMALL LETTER Z: zLEFT CURLY BRACKET:
{VERTICAL LINE: |RIGHT CURLY BRACKET:
}TILDE: ~
```
I believe they are broken as well.
> 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
Re: [PR] [MINVOKER-351] Escape special xml character in junit report [maven-invoker-plugin]
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118981114
With `StringEscapeUtils`:
```
NULL: START
OF HEADING: START OF TEXT: END OF TEXT:
END OF TRANSMISSION: ENQUIRY:
ACKNOWLEDGE: BELL: BACKSPACE:
CHARACTER TABULATION: LINE FEED (LF):
LINE TABULATION: FORM FEED (FF):
CARRIAGE RETURN (CR):
SHIFT OUT: SHIFT IN: DATA LINK
ESCAPE: DEVICE CONTROL ONE: DEVICE CONTROL TWO:
DEVICE CONTROL THREE: DEVICE CONTROL FOUR:
NEGATIVE ACKNOWLEDGE: SYNCHRONOUS IDLE:
END OF TRANSMISSION BLOCK: CANCEL: END
OF MEDIUM: SUBSTITUTE: ESCAPE:
INFORMATION SEPARATOR FOUR: INFORMATION SEPARATOR
THREE: INFORMATION SEPARATOR TWO: INFORMATION
SEPARATOR ONE: SPACE: EXCLAMATION MARK:
!QUOTATION MARK: quot;NUMBER SIGN:
#DOLLAR SIGN: $PERCENT SIGN: %AMPERSAND:
amp;APOSTROPHE: apos;LEFT PARENTHESIS:
(RIGHT PARENTHESIS: )ASTERISK: *PLUS
SIGN: +COMMA: ,HYPHEN-MINUS: -
FULL STOP: .SOLIDUS: /DIGIT ZERO:
0DIGIT ONE: 1DIGIT TWO: 2DIGIT THREE:
3DIGIT FOUR: 4DIGIT FIVE: 5DIGIT SIX:
6DIGIT SEVEN: 7DIGIT EIGHT: 8DIGIT NINE:
9COLON: :SEMICOLON: ;LESS-THAN SIGN:
lt;EQUALS SIGN: =GREATER-THAN SIGN:
gt;QUESTION MARK: ?COMMERCIAL AT:
@LATIN CAPITAL LETTER A: ALATIN CAPITAL LETTER B:
BLATIN CAPITAL LETTER C: CLATIN CAPITAL LETTER D:
DLATIN CAPITAL LETTER E: ELATIN CAPITAL LETTER F:
FLATIN CAPITAL LETTER G: GLATIN CAPITAL LETTER H:
HLATIN CAPITAL LETTER I: ILATIN CAPITAL LETTER J:
JLATIN CAPITAL LETTER K: KLATIN CAPITAL LETTER L:
LLATIN CAPITAL LETTER M: M
LATIN CAPITAL LETTER N: NLATIN CAPITAL LETTER O:
OLATIN CAPITAL LETTER P: PLATIN CAPITAL LETTER Q:
QLATIN CAPITAL LETTER R: RLATIN CAPITAL LETTER S:
SLATIN CAPITAL LETTER T: TLATIN CAPITAL LETTER U:
ULATIN CAPITAL LETTER V: VLATIN CAPITAL LETTER W:
WLATIN CAPITAL LETTER X: XLATIN CAPITAL LETTER Y:
YLATIN CAPITAL LETTER Z: ZLEFT SQUARE BRACKET:
[REVERSE SOLIDUS: \RIGHT SQUARE BRACKET:
]CIRCUMFLEX ACCENT: ^LOW LINE: _GRAVE
ACCENT: `LATIN SMALL LETTER A: aLATIN SMALL LETTER B:
bLATIN SMALL LETTER C: cLATIN SMALL LETTER D:
dLATIN SMALL LETTER E: eLATIN SMALL LETTER F:
fLATIN SMALL LETTER G: gLATIN SMALL LETTER H:
hLATIN SMALL LET
TER I: iLATIN SMALL LETTER J: jLATIN SMALL LETTER K:
kLATIN SMALL LETTER L: lLATIN SMALL LETTER M:
mLATIN SMALL LETTER N: nLATIN SMALL LETTER O:
oLATIN SMALL LETTER P: pLATIN SMALL LETTER Q:
qLATIN SMALL LETTER R: rLATIN SMALL LETTER S:
sLATIN SMALL LETTER T: tLATIN SMALL LETTER U:
uLATIN SMALL LETTER V: vLATIN SMALL LETTER W:
wLATIN SMALL LETTER X: xLATIN SMALL LETTER Y:
yLATIN SMALL LETTER Z: zLEFT CURLY BRACKET:
{VERTICAL LINE: |RIGHT CURLY BRACKET:
}TILDE: ~
```
I believe they are broken as well.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[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=17847587#comment-17847587
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118979631
Counterpart with Plexus:
```
MXSerializer sr = new MXSerializer();
sr.setOutput(System.out, "UTF-8");
sr.startDocument(null, Boolean.TRUE);
sr.startTag(null, "root");
for (int i = 0; i < Byte.MAX_VALUE; i++) {
sr.startTag(null, "char");
sr.text(Character.getName(i) + ": " + ((char) i));
sr.endTag(null, "char");
}
sr.endTag(null, "root");
sr.endDocument();
```
output:
```
Exception in thread "main" java.lang.IllegalStateException: character 0 is
not allowed in output
at
org.codehaus.plexus.util.xml.pull.MXSerializer.writeElementContent(MXSerializer.java:947)
at
org.codehaus.plexus.util.xml.pull.MXSerializer.text(MXSerializer.java:780)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.main(DefaultSiteRenderer.java:955)
```
> 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 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
Re: [PR] [MINVOKER-351] Escape special xml character in junit report [maven-invoker-plugin]
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118979631
Counterpart with Plexus:
```
MXSerializer sr = new MXSerializer();
sr.setOutput(System.out, "UTF-8");
sr.startDocument(null, Boolean.TRUE);
sr.startTag(null, "root");
for (int i = 0; i < Byte.MAX_VALUE; i++) {
sr.startTag(null, "char");
sr.text(Character.getName(i) + ": " + ((char) i));
sr.endTag(null, "char");
}
sr.endTag(null, "root");
sr.endDocument();
```
output:
```
Exception in thread "main" java.lang.IllegalStateException: character 0 is
not allowed in output
at
org.codehaus.plexus.util.xml.pull.MXSerializer.writeElementContent(MXSerializer.java:947)
at
org.codehaus.plexus.util.xml.pull.MXSerializer.text(MXSerializer.java:780)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.main(DefaultSiteRenderer.java:955)
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[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=17847586#comment-17847586
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118973031
@elharo is right. This is how it should look like:
```java
public static void main(String[] args) throws
ParserConfigurationException, TransformerException {
Document doc =
DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument();
Element root = doc.createElement("root");
for (int i = 0; i < Byte.MAX_VALUE; i++) {
Element elem = doc.createElement("char");
elem.setTextContent(Character.getName(i) + ": " +
((char) i));
root.appendChild(elem);
}
doc.appendChild(root);
DOMSource domSource = new DOMSource(doc);
StreamResult result = new StreamResult(System.out);
TransformerFactory tf = TransformerFactory.newInstance();
Transformer transformer = tf.newTransformer();
transformer.setOutputProperty(OutputKeys.INDENT, "yes");
transformer.setOutputProperty("{http://xml.apache.org/xslt}indent-amount;, "2");
transformer.transform(domSource, result);
}
```
output:
```
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further
details.
NULL:
START OF HEADING:
START OF TEXT:
END OF TEXT:
END OF TRANSMISSION:
ENQUIRY:
ACKNOWLEDGE:
BELL:
BACKSPACE:
CHARACTER TABULATION:
LINE FEED (LF):
LINE TABULATION:
FORM FEED (FF):
CARRIAGE RETURN (CR):
SHIFT OUT:
SHIFT IN:
DATA LINK ESCAPE:
DEVICE CONTROL ONE:
DEVICE CONTROL TWO:
DEVICE CONTROL THREE:
DEVICE CONTROL FOUR:
NEGATIVE ACKNOWLEDGE:
SYNCHRONOUS IDLE:
END OF TRANSMISSION BLOCK:
CANCEL:
END OF MEDIUM:
SUBSTITUTE:
ESCAPE:
INFORMATION SEPARATOR FOUR:
INFORMATION SEPARATOR THREE:
INFORMATION SEPARATOR TWO:
INFORMATION SEPARATOR ONE:
SPACE:
EXCLAMATION MARK: !
QUOTATION MARK: "
NUMBER SIGN: #
DOLLAR SIGN: $
PERCENT SIGN: %
AMPERSAND:
APOSTROPHE: '
LEFT PARENTHESIS: (
RIGHT PARENTHESIS: )
ASTERISK: *
PLUS SIGN: +
COMMA: ,
HYPHEN-MINUS: -
FULL STOP: .
SOLIDUS: /
DIGIT ZERO: 0
DIGIT ONE: 1
DIGIT TWO: 2
DIGIT THREE: 3
DIGIT FOUR: 4
DIGIT FIVE: 5
DIGIT SIX: 6
DIGIT SEVEN: 7
DIGIT EIGHT: 8
DIGIT NINE: 9
COLON: :
SEMICOLON: ;
LESS-THAN SIGN:
EQUALS SIGN: =
GREATER-THAN SIGN:
QUESTION MARK: ?
COMMERCIAL AT: @
LATIN CAPITAL LETTER A: A
LATIN CAPITAL LETTER B: B
LATIN CAPITAL LETTER C: C
LATIN CAPITAL LETTER D: D
LATIN CAPITAL LETTER E: E
LATIN CAPITAL LETTER F: F
LATIN CAPITAL LETTER G: G
LATIN CAPITAL LETTER H: H
LATIN CAPITAL LETTER I: I
LATIN CAPITAL LETTER J: J
LATIN CAPITAL LETTER K: K
LATIN CAPITAL LETTER L: L
LATIN CAPITAL LETTER M: M
LATIN CAPITAL LETTER N: N
LATIN CAPITAL LETTER O: O
LATIN CAPITAL LETTER P: P
LATIN CAPITAL LETTER Q: Q
LATIN CAPITAL LETTER R: R
LATIN CAPITAL LETTER S: S
LATIN CAPITAL LETTER T: T
LATIN CAPITAL LETTER U: U
LATIN CAPITAL LETTER V: V
LATIN CAPITAL LETTER W: W
LATIN CAPITAL LETTER X: X
LATIN CAPITAL LETTER Y: Y
LATIN CAPITAL LETTER Z: Z
LEFT SQUARE BRACKET: [
REVERSE SOLIDUS: \
RIGHT SQUARE BRACKET: ]
CIRCUMFLEX ACCENT: ^
LOW LINE: _
GRAVE ACCENT: `
LATIN SMALL LETTER A: a
LATIN SMALL LETTER B: b
LATIN SMALL LETTER C: c
LATIN SMALL LETTER D: d
LATIN SMALL LETTER E: e
LATIN SMALL LETTER F: f
LATIN SMALL LETTER G: g
LATIN SMALL LETTER H: h
LATIN SMALL LETTER I: i
LATIN SMALL LETTER J: j
LATIN SMALL LETTER K: k
LATIN SMALL LETTER L: l
LATIN SMALL LETTER M: m
LATIN SMALL LETTER N: n
LATIN SMALL LETTER O: o
LATIN SMALL LETTER P: p
LATIN SMALL LETTER Q: q
LATIN SMALL LETTER R: r
LATIN SMALL LETTER S: s
LATIN SMALL LETTER T: t
LATIN SMALL LETTER U: u
LATIN SMALL LETTER V: v
LATIN SMALL LETTER W: w
LATIN SMALL LETTER X: x
LATIN SMALL LETTER Y: y
LATIN SMALL LETTER Z: z
LEFT CURLY BRACKET: {
VERTICAL LINE: |
RIGHT CURLY BRACKET: }
TILDE: ~
```
which it does not with the
Re: [PR] [MINVOKER-351] Escape special xml character in junit report [maven-invoker-plugin]
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118973031
@elharo is right. This is how it should look like:
```java
public static void main(String[] args) throws
ParserConfigurationException, TransformerException {
Document doc =
DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument();
Element root = doc.createElement("root");
for (int i = 0; i < Byte.MAX_VALUE; i++) {
Element elem = doc.createElement("char");
elem.setTextContent(Character.getName(i) + ": " +
((char) i));
root.appendChild(elem);
}
doc.appendChild(root);
DOMSource domSource = new DOMSource(doc);
StreamResult result = new StreamResult(System.out);
TransformerFactory tf = TransformerFactory.newInstance();
Transformer transformer = tf.newTransformer();
transformer.setOutputProperty(OutputKeys.INDENT, "yes");
transformer.setOutputProperty("{http://xml.apache.org/xslt}indent-amount;, "2");
transformer.transform(domSource, result);
}
```
output:
```
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further
details.
NULL:
START OF HEADING:
START OF TEXT:
END OF TEXT:
END OF TRANSMISSION:
ENQUIRY:
ACKNOWLEDGE:
BELL:
BACKSPACE:
CHARACTER TABULATION:
LINE FEED (LF):
LINE TABULATION:
FORM FEED (FF):
CARRIAGE RETURN (CR):
SHIFT OUT:
SHIFT IN:
DATA LINK ESCAPE:
DEVICE CONTROL ONE:
DEVICE CONTROL TWO:
DEVICE CONTROL THREE:
DEVICE CONTROL FOUR:
NEGATIVE ACKNOWLEDGE:
SYNCHRONOUS IDLE:
END OF TRANSMISSION BLOCK:
CANCEL:
END OF MEDIUM:
SUBSTITUTE:
ESCAPE:
INFORMATION SEPARATOR FOUR:
INFORMATION SEPARATOR THREE:
INFORMATION SEPARATOR TWO:
INFORMATION SEPARATOR ONE:
SPACE:
EXCLAMATION MARK: !
QUOTATION MARK: "
NUMBER SIGN: #
DOLLAR SIGN: $
PERCENT SIGN: %
AMPERSAND:
APOSTROPHE: '
LEFT PARENTHESIS: (
RIGHT PARENTHESIS: )
ASTERISK: *
PLUS SIGN: +
COMMA: ,
HYPHEN-MINUS: -
FULL STOP: .
SOLIDUS: /
DIGIT ZERO: 0
DIGIT ONE: 1
DIGIT TWO: 2
DIGIT THREE: 3
DIGIT FOUR: 4
DIGIT FIVE: 5
DIGIT SIX: 6
DIGIT SEVEN: 7
DIGIT EIGHT: 8
DIGIT NINE: 9
COLON: :
SEMICOLON: ;
LESS-THAN SIGN:
EQUALS SIGN: =
GREATER-THAN SIGN:
QUESTION MARK: ?
COMMERCIAL AT: @
LATIN CAPITAL LETTER A: A
LATIN CAPITAL LETTER B: B
LATIN CAPITAL LETTER C: C
LATIN CAPITAL LETTER D: D
LATIN CAPITAL LETTER E: E
LATIN CAPITAL LETTER F: F
LATIN CAPITAL LETTER G: G
LATIN CAPITAL LETTER H: H
LATIN CAPITAL LETTER I: I
LATIN CAPITAL LETTER J: J
LATIN CAPITAL LETTER K: K
LATIN CAPITAL LETTER L: L
LATIN CAPITAL LETTER M: M
LATIN CAPITAL LETTER N: N
LATIN CAPITAL LETTER O: O
LATIN CAPITAL LETTER P: P
LATIN CAPITAL LETTER Q: Q
LATIN CAPITAL LETTER R: R
LATIN CAPITAL LETTER S: S
LATIN CAPITAL LETTER T: T
LATIN CAPITAL LETTER U: U
LATIN CAPITAL LETTER V: V
LATIN CAPITAL LETTER W: W
LATIN CAPITAL LETTER X: X
LATIN CAPITAL LETTER Y: Y
LATIN CAPITAL LETTER Z: Z
LEFT SQUARE BRACKET: [
REVERSE SOLIDUS: \
RIGHT SQUARE BRACKET: ]
CIRCUMFLEX ACCENT: ^
LOW LINE: _
GRAVE ACCENT: `
LATIN SMALL LETTER A: a
LATIN SMALL LETTER B: b
LATIN SMALL LETTER C: c
LATIN SMALL LETTER D: d
LATIN SMALL LETTER E: e
LATIN SMALL LETTER F: f
LATIN SMALL LETTER G: g
LATIN SMALL LETTER H: h
LATIN SMALL LETTER I: i
LATIN SMALL LETTER J: j
LATIN SMALL LETTER K: k
LATIN SMALL LETTER L: l
LATIN SMALL LETTER M: m
LATIN SMALL LETTER N: n
LATIN SMALL LETTER O: o
LATIN SMALL LETTER P: p
LATIN SMALL LETTER Q: q
LATIN SMALL LETTER R: r
LATIN SMALL LETTER S: s
LATIN SMALL LETTER T: t
LATIN SMALL LETTER U: u
LATIN SMALL LETTER V: v
LATIN SMALL LETTER W: w
LATIN SMALL LETTER X: x
LATIN SMALL LETTER Y: y
LATIN SMALL LETTER Z: z
LEFT CURLY BRACKET: {
VERTICAL LINE: |
RIGHT CURLY BRACKET: }
TILDE: ~
```
which it does not with the Plexus serializer. Means: Plexus serializer is
broken.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe,
[jira] [Commented] (DOXIASITETOOLS-340) Rearrange title order in Velocity context
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847585#comment-17847585
]
ASF GitHub Bot commented on DOXIASITETOOLS-340:
---
michael-o commented on PR #157:
URL:
https://github.com/apache/maven-doxia-sitetools/pull/157#issuecomment-2118953058
@kwin Is the change itself acceptable?
> Rearrange title order in Velocity context
> -
>
> Key: DOXIASITETOOLS-340
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-340
> Project: Maven Doxia Sitetools
> Issue Type: Dependency upgrade
> Components: Site renderer
>Affects Versions: 2.0.0-M18
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 2.0.0, 2.0.0-M19
>
>
> Currently, the title is set as follows:
> {projectName}} -- {{documentTitle}}
> This causes problems when you have multiple browsers tabs open, all you see
> is the project name not the document title, making is hard to identify. The
> common, today's approach is to go from specific to general: {{documentTitle}}
> -- {projectName}}. We should do the same.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIASITETOOLS-340] Rearrange title order in Velocity context [maven-doxia-sitetools]
michael-o commented on PR #157: URL: https://github.com/apache/maven-doxia-sitetools/pull/157#issuecomment-2118953058 @kwin Is the change itself acceptable? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[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=17847571#comment-17847571
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on code in PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#discussion_r1605818675
##
src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java:
##
@@ -1640,7 +1642,7 @@ private void runBuild(
}
} catch (RunFailureException e) {
buildJob.setResult(e.getType());
-buildJob.setFailureMessage(e.getMessage());
+
buildJob.setFailureMessage(StringEscapeUtils.escapeXml10(e.getMessage()));
Review Comment:
> Assuming buildJob is just an object that contains strings and other
things, but has no particular XML internals (like 99.9% of classes that contain
strings) nothing inside it should be escaped.
>
> Ideally the XML writer should escape strings when it needs to. Or is the
XML writer is broken and won't do that, then the escaping should be done after
the string is extracted from the buildJob and before it's passed to the writer.
Escaping strings inside the buildJob breaks its semantics and tightly couples
all the classes together in one particularly brittle path.
Yes, the XML writer is broken and needs an issue.
> 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 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
Re: [PR] [MINVOKER-351] Escape special xml character in junit report [maven-invoker-plugin]
michael-o commented on code in PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#discussion_r1605818675
##
src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java:
##
@@ -1640,7 +1642,7 @@ private void runBuild(
}
} catch (RunFailureException e) {
buildJob.setResult(e.getType());
-buildJob.setFailureMessage(e.getMessage());
+
buildJob.setFailureMessage(StringEscapeUtils.escapeXml10(e.getMessage()));
Review Comment:
> Assuming buildJob is just an object that contains strings and other
things, but has no particular XML internals (like 99.9% of classes that contain
strings) nothing inside it should be escaped.
>
> Ideally the XML writer should escape strings when it needs to. Or is the
XML writer is broken and won't do that, then the escaping should be done after
the string is extracted from the buildJob and before it's passed to the writer.
Escaping strings inside the buildJob breaks its semantics and tightly couples
all the classes together in one particularly brittle path.
Yes, the XML writer is broken and needs an issue.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (DOXIASITETOOLS-340) Rearrange title order in Velocity context
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847570#comment-17847570
]
ASF GitHub Bot commented on DOXIASITETOOLS-340:
---
michael-o commented on PR #157:
URL:
https://github.com/apache/maven-doxia-sitetools/pull/157#issuecomment-2118881121
> This contradicts the description in
https://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html#Title.
Issue created: https://issues.apache.org/jira/browse/MSITE-1007
> Rearrange title order in Velocity context
> -
>
> Key: DOXIASITETOOLS-340
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-340
> Project: Maven Doxia Sitetools
> Issue Type: Dependency upgrade
> Components: Site renderer
>Affects Versions: 2.0.0-M18
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 2.0.0, 2.0.0-M19
>
>
> Currently, the title is set as follows:
> {projectName}} -- {{documentTitle}}
> This causes problems when you have multiple browsers tabs open, all you see
> is the project name not the document title, making is hard to identify. The
> common, today's approach is to go from specific to general: {{documentTitle}}
> -- {projectName}}. We should do the same.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIASITETOOLS-340] Rearrange title order in Velocity context [maven-doxia-sitetools]
michael-o commented on PR #157: URL: https://github.com/apache/maven-doxia-sitetools/pull/157#issuecomment-2118881121 > This contradicts the description in https://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html#Title. Issue created: https://issues.apache.org/jira/browse/MSITE-1007 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MSITE-1007) Review "Configuring the Site Descriptor" for new site model and behavior
Michael Osipov created MSITE-1007: - Summary: Review "Configuring the Site Descriptor" for new site model and behavior Key: MSITE-1007 URL: https://issues.apache.org/jira/browse/MSITE-1007 Project: Maven Site Plugin Issue Type: Task Components: documentation Affects Versions: 4.0.0-M14 Reporter: Michael Osipov -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Update artifact-handlers.apt [maven]
kwin commented on PR #1466: URL: https://github.com/apache/maven/pull/1466#issuecomment-2118853443 No consensus here, therefore closing. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Update artifact-handlers.apt [maven]
kwin closed pull request #1466: Update artifact-handlers.apt URL: https://github.com/apache/maven/pull/1466 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-8097) Validate that each dependency->type is a type registered in an artifact handler
[
https://issues.apache.org/jira/browse/MNG-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847553#comment-17847553
]
ASF GitHub Bot commented on MNG-8097:
-
kwin opened a new pull request, #529:
URL: https://github.com/apache/maven-site/pull/529
(with a related artifact handler)
> Validate that each dependency->type is a type registered in an artifact
> handler
> ---
>
> Key: MNG-8097
> URL: https://issues.apache.org/jira/browse/MNG-8097
> Project: Maven
> Issue Type: New Feature
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently often the dependency's type is being set to the extension and the
> resolution is lenient, i.e. if there is no artifact handler defining the
> value given in {{dependency->type}} resolution transparently uses the type as
> extension.
> That can potentially lead to two issues:
> 1. Resolution might fail with surprising error messages like
> {code}
> Could not resolve dependencies for project : The following artifacts
> could not be resolved: : Could not transfer artifact
> ::: from/to ...
> {code}
> This is an issue for all types not defined by Maven Core itself, e.g. for
> https://jackrabbit.apache.org/filevault-package-maven-plugin/index.html which
> registers an artifact handler for type {{content-package}} with extension
> {{zip}}.
> 2. The information {{addedToClasspath}}, {{includesDependencies}} and
> {{classifier}} from the artifact handler is not evaluated
> Compare with
> https://maven.apache.org/repositories/artifacts.html#but-where-do-i-set-artifact-extension
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [MNG-8097] Outline the two different ways to reference a dependency [maven-site]
kwin opened a new pull request, #529: URL: https://github.com/apache/maven-site/pull/529 (with a related artifact handler) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-8097) Validate that each dependency->type is a type registered in an artifact handler
[
https://issues.apache.org/jira/browse/MNG-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MNG-8097:
-
Description:
Currently often the dependency's type is being set to the extension and the
resolution is lenient, i.e. if there is no artifact handler defining the value
given in {{dependency->type}} resolution transparently uses the type as
extension.
That can potentially lead to two issues:
1. Resolution might fail with surprising error messages like
{code}
Could not resolve dependencies for project : The following artifacts could
not be resolved: : Could not transfer artifact
::: from/to ...
{code}
This is an issue for all types not defined by Maven Core itself, e.g. for
https://jackrabbit.apache.org/filevault-package-maven-plugin/index.html which
registers an artifact handler for type {{content-package}} with extension
{{zip}}.
2. The information {{addedToClasspath}}, {{includesDependencies}} and
{{classifier}} from the artifact handler is not evaluated
Compare with
https://maven.apache.org/repositories/artifacts.html#but-where-do-i-set-artifact-extension
was:
Currently often the dependency's type is being set to the extension and the
resolution is lenient, i.e. if there is no artifact handler defining the value
given in {{dependency->type}} resolution transparently uses the type as
extension.
That can potentially lead to two issues:
1. Resolution might fail with surprising error messages like
{code}
Could not resolve dependencies for project : The following artifacts could
not be resolved: : Could not transfer artifact
::: from/to ...
{code}
This is an issue for all types not defined by Maven Core itself, e.g. for
https://jackrabbit.apache.org/filevault-package-maven-plugin/index.html which
registers an artifact handler for type {{content-package}} with extension
{{zip}}.
2. The information {{addedToClasspath}}, {{includesDependencies}} and
{{classifier}} from the artifact handler is not evaluated
> Validate that each dependency->type is a type registered in an artifact
> handler
> ---
>
> Key: MNG-8097
> URL: https://issues.apache.org/jira/browse/MNG-8097
> Project: Maven
> Issue Type: New Feature
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently often the dependency's type is being set to the extension and the
> resolution is lenient, i.e. if there is no artifact handler defining the
> value given in {{dependency->type}} resolution transparently uses the type as
> extension.
> That can potentially lead to two issues:
> 1. Resolution might fail with surprising error messages like
> {code}
> Could not resolve dependencies for project : The following artifacts
> could not be resolved: : Could not transfer artifact
> ::: from/to ...
> {code}
> This is an issue for all types not defined by Maven Core itself, e.g. for
> https://jackrabbit.apache.org/filevault-package-maven-plugin/index.html which
> registers an artifact handler for type {{content-package}} with extension
> {{zip}}.
> 2. The information {{addedToClasspath}}, {{includesDependencies}} and
> {{classifier}} from the artifact handler is not evaluated
> Compare with
> https://maven.apache.org/repositories/artifacts.html#but-where-do-i-set-artifact-extension
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-340) Rearrange title order in Velocity context
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847547#comment-17847547
]
ASF GitHub Bot commented on DOXIASITETOOLS-340:
---
michael-o commented on PR #157:
URL:
https://github.com/apache/maven-doxia-sitetools/pull/157#issuecomment-2118842620
> This contradicts the description in
https://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html#Title.
As a side note, this page needs a complete rework for the new site model.
> Rearrange title order in Velocity context
> -
>
> Key: DOXIASITETOOLS-340
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-340
> Project: Maven Doxia Sitetools
> Issue Type: Dependency upgrade
> Components: Site renderer
>Affects Versions: 2.0.0-M18
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 2.0.0, 2.0.0-M19
>
>
> Currently, the title is set as follows:
> {projectName}} -- {{documentTitle}}
> This causes problems when you have multiple browsers tabs open, all you see
> is the project name not the document title, making is hard to identify. The
> common, today's approach is to go from specific to general: {{documentTitle}}
> -- {projectName}}. We should do the same.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIASITETOOLS-340] Rearrange title order in Velocity context [maven-doxia-sitetools]
michael-o commented on PR #157: URL: https://github.com/apache/maven-doxia-sitetools/pull/157#issuecomment-2118842620 > This contradicts the description in https://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html#Title. As a side note, this page needs a complete rework for the new site model. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MNG-8050) Same repositories IDs in settings.xml and POM are not detected
[
https://issues.apache.org/jira/browse/MNG-8050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus closed MNG-8050.
> Same repositories IDs in settings.xml and POM are not detected
> --
>
> Key: MNG-8050
> URL: https://issues.apache.org/jira/browse/MNG-8050
> Project: Maven
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 4.0.0, 4.0.0-beta-3
>
>
> When the same repository ID is used in repositories defined in
> # {{settings.xml}} and
> # POM
> the one from the POM is just silently ignored and no ERROR is emitted.
> OTOH when defining repositories with the same ID in POM the following error
> is emitted:
> {code}
> [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] 'repositories.repository.id' must be unique
> {code}
> A similar error should be emitted for repository ID clashes in
> {{settings.xml}} (both local and global) and POM
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MNG-8050) Same repositories IDs in settings.xml and POM are not detected
[
https://issues.apache.org/jira/browse/MNG-8050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved MNG-8050.
--
Fix Version/s: 4.0.0
4.0.0-beta-3
Resolution: Fixed
Fixed in
https://github.com/apache/maven/commit/ac80eeabc4cf28199cf65cb58b27eae590b3d16a.
> Same repositories IDs in settings.xml and POM are not detected
> --
>
> Key: MNG-8050
> URL: https://issues.apache.org/jira/browse/MNG-8050
> Project: Maven
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 4.0.0, 4.0.0-beta-3
>
>
> When the same repository ID is used in repositories defined in
> # {{settings.xml}} and
> # POM
> the one from the POM is just silently ignored and no ERROR is emitted.
> OTOH when defining repositories with the same ID in POM the following error
> is emitted:
> {code}
> [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] 'repositories.repository.id' must be unique
> {code}
> A similar error should be emitted for repository ID clashes in
> {{settings.xml}} (both local and global) and POM
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8050) Same repositories IDs in settings.xml and POM are not detected
[
https://issues.apache.org/jira/browse/MNG-8050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847539#comment-17847539
]
ASF GitHub Bot commented on MNG-8050:
-
kwin merged PR #1412:
URL: https://github.com/apache/maven/pull/1412
> Same repositories IDs in settings.xml and POM are not detected
> --
>
> Key: MNG-8050
> URL: https://issues.apache.org/jira/browse/MNG-8050
> Project: Maven
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> When the same repository ID is used in repositories defined in
> # {{settings.xml}} and
> # POM
> the one from the POM is just silently ignored and no ERROR is emitted.
> OTOH when defining repositories with the same ID in POM the following error
> is emitted:
> {code}
> [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] 'repositories.repository.id' must be unique
> {code}
> A similar error should be emitted for repository ID clashes in
> {{settings.xml}} (both local and global) and POM
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-8050] emit warn in case of repo id clashes between settings and POM [maven]
kwin merged PR #1412: URL: https://github.com/apache/maven/pull/1412 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (DOXIASITETOOLS-340) Rearrange title order in Velocity context
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847537#comment-17847537
]
ASF GitHub Bot commented on DOXIASITETOOLS-340:
---
michael-o commented on PR #157:
URL:
https://github.com/apache/maven-doxia-sitetools/pull/157#issuecomment-2118834522
> This contradicts the description in
https://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html#Title.
Good catch, will update.
> Rearrange title order in Velocity context
> -
>
> Key: DOXIASITETOOLS-340
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-340
> Project: Maven Doxia Sitetools
> Issue Type: Dependency upgrade
> Components: Site renderer
>Affects Versions: 2.0.0-M18
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 2.0.0, 2.0.0-M19
>
>
> Currently, the title is set as follows:
> {projectName}} -- {{documentTitle}}
> This causes problems when you have multiple browsers tabs open, all you see
> is the project name not the document title, making is hard to identify. The
> common, today's approach is to go from specific to general: {{documentTitle}}
> -- {projectName}}. We should do the same.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIASITETOOLS-340] Rearrange title order in Velocity context [maven-doxia-sitetools]
michael-o commented on PR #157: URL: https://github.com/apache/maven-doxia-sitetools/pull/157#issuecomment-2118834522 > This contradicts the description in https://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html#Title. Good catch, will update. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (DOXIASITETOOLS-340) Rearrange title order in Velocity context
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847533#comment-17847533
]
ASF GitHub Bot commented on DOXIASITETOOLS-340:
---
kwin commented on PR #157:
URL:
https://github.com/apache/maven-doxia-sitetools/pull/157#issuecomment-2118832433
This contradicts the description in
https://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html#Title.
> Rearrange title order in Velocity context
> -
>
> Key: DOXIASITETOOLS-340
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-340
> Project: Maven Doxia Sitetools
> Issue Type: Dependency upgrade
> Components: Site renderer
>Affects Versions: 2.0.0-M18
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 2.0.0, 2.0.0-M19
>
>
> Currently, the title is set as follows:
> {projectName}} -- {{documentTitle}}
> This causes problems when you have multiple browsers tabs open, all you see
> is the project name not the document title, making is hard to identify. The
> common, today's approach is to go from specific to general: {{documentTitle}}
> -- {projectName}}. We should do the same.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIASITETOOLS-340] Rearrange title order in Velocity context [maven-doxia-sitetools]
kwin commented on PR #157: URL: https://github.com/apache/maven-doxia-sitetools/pull/157#issuecomment-2118832433 This contradicts the description in https://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html#Title. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-8050) Same repositories IDs in settings.xml and POM are not detected
[
https://issues.apache.org/jira/browse/MNG-8050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847531#comment-17847531
]
ASF GitHub Bot commented on MNG-8050:
-
kwin commented on PR #1412:
URL: https://github.com/apache/maven/pull/1412#issuecomment-2118831511
> I think we should also warn if the URL is equal but the flags
for either or differ. Otherwise this might lead to subtle
issues which are hard to debug.
I decided to ignore those subtle differences for now.
> Same repositories IDs in settings.xml and POM are not detected
> --
>
> Key: MNG-8050
> URL: https://issues.apache.org/jira/browse/MNG-8050
> Project: Maven
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> When the same repository ID is used in repositories defined in
> # {{settings.xml}} and
> # POM
> the one from the POM is just silently ignored and no ERROR is emitted.
> OTOH when defining repositories with the same ID in POM the following error
> is emitted:
> {code}
> [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] 'repositories.repository.id' must be unique
> {code}
> A similar error should be emitted for repository ID clashes in
> {{settings.xml}} (both local and global) and POM
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[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=17847528#comment-17847528
]
ASF GitHub Bot commented on MINVOKER-351:
-
elharo commented on code in PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#discussion_r1605791199
##
src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java:
##
@@ -1640,7 +1642,7 @@ private void runBuild(
}
} catch (RunFailureException e) {
buildJob.setResult(e.getType());
-buildJob.setFailureMessage(e.getMessage());
+
buildJob.setFailureMessage(StringEscapeUtils.escapeXml10(e.getMessage()));
Review Comment:
Assuming buildJob is just an object that contains strings and other things,
but has no particular XML internals (like 99.9% of classes that contain
strings) nothing inside it should be escaped.
Ideally the XML writer should escape strings when it needs to. Or is the XML
writer is broken and won't do that, then the escaping should be done after the
string is extracted from the buildJob and before it's passed to the writer.
Escaping strings inside the buildJob breaks its semantics and tightly couples
all the classes together in one particularly brittle path.
> 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 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
Re: [PR] [MINVOKER-351] Escape special xml character in junit report [maven-invoker-plugin]
elharo commented on code in PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#discussion_r1605791199
##
src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java:
##
@@ -1640,7 +1642,7 @@ private void runBuild(
}
} catch (RunFailureException e) {
buildJob.setResult(e.getType());
-buildJob.setFailureMessage(e.getMessage());
+
buildJob.setFailureMessage(StringEscapeUtils.escapeXml10(e.getMessage()));
Review Comment:
Assuming buildJob is just an object that contains strings and other things,
but has no particular XML internals (like 99.9% of classes that contain
strings) nothing inside it should be escaped.
Ideally the XML writer should escape strings when it needs to. Or is the XML
writer is broken and won't do that, then the escaping should be done after the
string is extracted from the buildJob and before it's passed to the writer.
Escaping strings inside the buildJob breaks its semantics and tightly couples
all the classes together in one particularly brittle path.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MJAR-310) [REGRESSION] Plugin fails to handle toolchain paths that contain spaces
[
https://issues.apache.org/jira/browse/MJAR-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847527#comment-17847527
]
ASF GitHub Bot commented on MJAR-310:
-
jansohn commented on PR #86:
URL: https://github.com/apache/maven-jar-plugin/pull/86#issuecomment-2118827018
> @jansohn can you try my proposition of fix: #87
I can test it on Tuesday but I doubt it will fix the problem.
> [REGRESSION] Plugin fails to handle toolchain paths that contain spaces
> ---
>
> Key: MJAR-310
> URL: https://issues.apache.org/jira/browse/MJAR-310
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 3.4.0, 3.4.1
> Environment: Maven 3.9.6
> Windows 10
>Reporter: Gili
>Priority: Major
> Fix For: next-release
>
>
> When upgrading from version 3.3.0 to 3.4.0 I started getting the following
> build-time warning:
>
> {{[WARNING] Unrecognized output form C:\Program
> Files\Java\zulu-8\bin\javac.exe -version - 'C:\Program' is not recognized as
> an internal or external command,}}
> {{operable program or batch file.}}
>
> The contents of toolchain.xml is:
>
> {{}}
> {{}}
> {{ }}
> {{ jdk}}
> {{ }}
> {{ 8}}
> {{ zulu}}
> {{ }}
> {{ }}
> {{ C:\Program Files\Java\zulu-8}}
> {{ }}
> {{ }}
> {{}}
>
> I don't know if this warning breaks anything.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAR-310) [REGRESSION] Plugin fails to handle toolchain paths that contain spaces
[
https://issues.apache.org/jira/browse/MJAR-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847526#comment-17847526
]
ASF GitHub Bot commented on MJAR-310:
-
jansohn commented on PR #86:
URL: https://github.com/apache/maven-jar-plugin/pull/86#issuecomment-2118826793
> @jansohn - please look at comments in JIRA
https://issues.apache.org/jira/browse/MJAR-310
> It can be reasonable to fix a bug in plexus-utils
Makes sense but there are already three year old PRs trying to revert the
extra use of cmd.exe so I'm not keen on going down that route.
I think it makes more sense to just use ProcessBuilder directly for such a
simple task.
> [REGRESSION] Plugin fails to handle toolchain paths that contain spaces
> ---
>
> Key: MJAR-310
> URL: https://issues.apache.org/jira/browse/MJAR-310
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 3.4.0, 3.4.1
> Environment: Maven 3.9.6
> Windows 10
>Reporter: Gili
>Priority: Major
> Fix For: next-release
>
>
> When upgrading from version 3.3.0 to 3.4.0 I started getting the following
> build-time warning:
>
> {{[WARNING] Unrecognized output form C:\Program
> Files\Java\zulu-8\bin\javac.exe -version - 'C:\Program' is not recognized as
> an internal or external command,}}
> {{operable program or batch file.}}
>
> The contents of toolchain.xml is:
>
> {{}}
> {{}}
> {{ }}
> {{ jdk}}
> {{ }}
> {{ 8}}
> {{ zulu}}
> {{ }}
> {{ }}
> {{ C:\Program Files\Java\zulu-8}}
> {{ }}
> {{ }}
> {{}}
>
> I don't know if this warning breaks anything.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MJAR-310] - fixed toolchain version detection when toolchain paths contain white spaces [maven-jar-plugin]
jansohn commented on PR #86: URL: https://github.com/apache/maven-jar-plugin/pull/86#issuecomment-2118827018 > @jansohn can you try my proposition of fix: #87 I can test it on Tuesday but I doubt it will fix the problem. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MJAR-310] - fixed toolchain version detection when toolchain paths contain white spaces [maven-jar-plugin]
jansohn commented on PR #86: URL: https://github.com/apache/maven-jar-plugin/pull/86#issuecomment-2118826793 > @jansohn - please look at comments in JIRA https://issues.apache.org/jira/browse/MJAR-310 > It can be reasonable to fix a bug in plexus-utils Makes sense but there are already three year old PRs trying to revert the extra use of cmd.exe so I'm not keen on going down that route. I think it makes more sense to just use ProcessBuilder directly for such a simple task. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MJAR-310) [REGRESSION] Plugin fails to handle toolchain paths that contain spaces
[
https://issues.apache.org/jira/browse/MJAR-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847522#comment-17847522
]
ASF GitHub Bot commented on MJAR-310:
-
jansohn commented on PR #86:
URL: https://github.com/apache/maven-jar-plugin/pull/86#issuecomment-2118823265
> @jansohn can you try my proposition of fix: #87
I'll only be back in the office on Tuesday to give it a try. But I'd be
surprised if this actually fixed the problem.
> [REGRESSION] Plugin fails to handle toolchain paths that contain spaces
> ---
>
> Key: MJAR-310
> URL: https://issues.apache.org/jira/browse/MJAR-310
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 3.4.0, 3.4.1
> Environment: Maven 3.9.6
> Windows 10
>Reporter: Gili
>Priority: Major
> Fix For: next-release
>
>
> When upgrading from version 3.3.0 to 3.4.0 I started getting the following
> build-time warning:
>
> {{[WARNING] Unrecognized output form C:\Program
> Files\Java\zulu-8\bin\javac.exe -version - 'C:\Program' is not recognized as
> an internal or external command,}}
> {{operable program or batch file.}}
>
> The contents of toolchain.xml is:
>
> {{}}
> {{}}
> {{ }}
> {{ jdk}}
> {{ }}
> {{ 8}}
> {{ zulu}}
> {{ }}
> {{ }}
> {{ C:\Program Files\Java\zulu-8}}
> {{ }}
> {{ }}
> {{}}
>
> I don't know if this warning breaks anything.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MJAR-310] - fixed toolchain version detection when toolchain paths contain white spaces [maven-jar-plugin]
jansohn commented on PR #86: URL: https://github.com/apache/maven-jar-plugin/pull/86#issuecomment-2118823265 > @jansohn can you try my proposition of fix: #87 I'll only be back in the office on Tuesday to give it a try. But I'd be surprised if this actually fixed the problem. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MJAR-310) [REGRESSION] Plugin fails to handle toolchain paths that contain spaces
[
https://issues.apache.org/jira/browse/MJAR-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847518#comment-17847518
]
ASF GitHub Bot commented on MJAR-310:
-
slawekjaranowski commented on PR #86:
URL: https://github.com/apache/maven-jar-plugin/pull/86#issuecomment-2118816933
@jansohn can you try my proposition of fix: #87
> [REGRESSION] Plugin fails to handle toolchain paths that contain spaces
> ---
>
> Key: MJAR-310
> URL: https://issues.apache.org/jira/browse/MJAR-310
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 3.4.0, 3.4.1
> Environment: Maven 3.9.6
> Windows 10
>Reporter: Gili
>Priority: Major
> Fix For: next-release
>
>
> When upgrading from version 3.3.0 to 3.4.0 I started getting the following
> build-time warning:
>
> {{[WARNING] Unrecognized output form C:\Program
> Files\Java\zulu-8\bin\javac.exe -version - 'C:\Program' is not recognized as
> an internal or external command,}}
> {{operable program or batch file.}}
>
> The contents of toolchain.xml is:
>
> {{}}
> {{}}
> {{ }}
> {{ jdk}}
> {{ }}
> {{ 8}}
> {{ zulu}}
> {{ }}
> {{ }}
> {{ C:\Program Files\Java\zulu-8}}
> {{ }}
> {{ }}
> {{}}
>
> I don't know if this warning breaks anything.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MJAR-310] - fixed toolchain version detection when toolchain paths contain white spaces [maven-jar-plugin]
slawekjaranowski commented on PR #86: URL: https://github.com/apache/maven-jar-plugin/pull/86#issuecomment-2118816933 @jansohn can you try my proposition of fix: #87 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MJAR-310) [REGRESSION] Plugin fails to handle toolchain paths that contain spaces
[
https://issues.apache.org/jira/browse/MJAR-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847517#comment-17847517
]
ASF GitHub Bot commented on MJAR-310:
-
slawekjaranowski opened a new pull request, #87:
URL: https://github.com/apache/maven-jar-plugin/pull/87
Following this checklist to help us incorporate your
contribution quickly and easily:
- [ ] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/MJAR) filed
for the change (usually before you start working on it). Trivial
changes like typos do not
require a JIRA issue. Your pull request should address just this
issue, without
pulling in other changes.
- [ ] Each commit in the pull request should have a meaningful subject line
and body.
- [ ] Format the pull request title like `[MJAR-XXX] - Fixes bug in
ApproximateQuantiles`,
where you replace `MJAR-XXX` with the appropriate JIRA issue. Best
practice
is to use the JIRA issue title in the pull request title and in the
first line of the
commit message.
- [ ] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [ ] Run `mvn clean verify` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [ ] You have run the integration tests successfully (`mvn -Prun-its clean
verify`).
If your pull request is about ~20 lines of code you don't need to sign an
[Individual Contributor License
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [ ] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [ ] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
> [REGRESSION] Plugin fails to handle toolchain paths that contain spaces
> ---
>
> Key: MJAR-310
> URL: https://issues.apache.org/jira/browse/MJAR-310
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 3.4.0, 3.4.1
> Environment: Maven 3.9.6
> Windows 10
>Reporter: Gili
>Priority: Major
> Fix For: next-release
>
>
> When upgrading from version 3.3.0 to 3.4.0 I started getting the following
> build-time warning:
>
> {{[WARNING] Unrecognized output form C:\Program
> Files\Java\zulu-8\bin\javac.exe -version - 'C:\Program' is not recognized as
> an internal or external command,}}
> {{operable program or batch file.}}
>
> The contents of toolchain.xml is:
>
> {{}}
> {{}}
> {{ }}
> {{ jdk}}
> {{ }}
> {{ 8}}
> {{ zulu}}
> {{ }}
> {{ }}
> {{ C:\Program Files\Java\zulu-8}}
> {{ }}
> {{ }}
> {{}}
>
> I don't know if this warning breaks anything.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [MJAR-310] fixed toolchain version detection when toolchain paths contain white spaces [maven-jar-plugin]
slawekjaranowski opened a new pull request, #87: URL: https://github.com/apache/maven-jar-plugin/pull/87 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MJAR) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MJAR-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MJAR-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[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=17847515#comment-17847515
]
ASF GitHub Bot commented on MINVOKER-351:
-
slawekjaranowski commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118810846
@michael-o IT improved according to hints
> 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 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
Re: [PR] [MINVOKER-351] Escape special xml character in junit report [maven-invoker-plugin]
slawekjaranowski commented on PR #242: URL: https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118810846 @michael-o IT improved according to hints -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[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=17847513#comment-17847513
]
ASF GitHub Bot commented on MINVOKER-351:
-
slawekjaranowski commented on code in PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#discussion_r1605783758
##
src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java:
##
@@ -1640,7 +1642,7 @@ private void runBuild(
}
} catch (RunFailureException e) {
buildJob.setResult(e.getType());
-buildJob.setFailureMessage(e.getMessage());
+
buildJob.setFailureMessage(StringEscapeUtils.escapeXml10(e.getMessage()));
Review Comment:
In other place message is produced in code and we sure that does not
contains special chars.
Only `exception.getMessage()` can return everything
> 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 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 {{}}
Re: [PR] [MINVOKER-351] Escape special xml character in junit report [maven-invoker-plugin]
slawekjaranowski commented on code in PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#discussion_r1605783758
##
src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java:
##
@@ -1640,7 +1642,7 @@ private void runBuild(
}
} catch (RunFailureException e) {
buildJob.setResult(e.getType());
-buildJob.setFailureMessage(e.getMessage());
+
buildJob.setFailureMessage(StringEscapeUtils.escapeXml10(e.getMessage()));
Review Comment:
In other place message is produced in code and we sure that does not
contains special chars.
Only `exception.getMessage()` can return everything
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MJAR-310) [REGRESSION] Plugin fails to handle toolchain paths that contain spaces
[
https://issues.apache.org/jira/browse/MJAR-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847512#comment-17847512
]
ASF GitHub Bot commented on MJAR-310:
-
slawekjaranowski commented on PR #86:
URL: https://github.com/apache/maven-jar-plugin/pull/86#issuecomment-2118807695
@jansohn - please look at comments in JIRA
https://issues.apache.org/jira/browse/MJAR-310
It can be reasonable to fix a bug in plexus-utils
> [REGRESSION] Plugin fails to handle toolchain paths that contain spaces
> ---
>
> Key: MJAR-310
> URL: https://issues.apache.org/jira/browse/MJAR-310
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 3.4.0, 3.4.1
> Environment: Maven 3.9.6
> Windows 10
>Reporter: Gili
>Priority: Major
> Fix For: next-release
>
>
> When upgrading from version 3.3.0 to 3.4.0 I started getting the following
> build-time warning:
>
> {{[WARNING] Unrecognized output form C:\Program
> Files\Java\zulu-8\bin\javac.exe -version - 'C:\Program' is not recognized as
> an internal or external command,}}
> {{operable program or batch file.}}
>
> The contents of toolchain.xml is:
>
> {{}}
> {{}}
> {{ }}
> {{ jdk}}
> {{ }}
> {{ 8}}
> {{ zulu}}
> {{ }}
> {{ }}
> {{ C:\Program Files\Java\zulu-8}}
> {{ }}
> {{ }}
> {{}}
>
> I don't know if this warning breaks anything.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MJAR-310] - fixed toolchain version detection when toolchain paths contain white spaces [maven-jar-plugin]
slawekjaranowski commented on PR #86: URL: https://github.com/apache/maven-jar-plugin/pull/86#issuecomment-2118807695 @jansohn - please look at comments in JIRA https://issues.apache.org/jira/browse/MJAR-310 It can be reasonable to fix a bug in plexus-utils -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[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=17847509#comment-17847509
]
Michael Osipov commented on MINVOKER-351:
-
The behavior is inconsitent because plugins are a moving target. One must pin
all relevant plugins otherwise the behavior will vary.
> 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 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}}
[jira] [Created] (DOXIASITETOOLS-341) Upgrade plugins and components (in ITs)
Michael Osipov created DOXIASITETOOLS-341: - Summary: Upgrade plugins and components (in ITs) Key: DOXIASITETOOLS-341 URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-341 Project: Maven Doxia Sitetools Issue Type: Dependency upgrade Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 2.0.0, 2.0.0-M19 * Upgrade to Doxia 2.0.0-M12 * Upgrade to Maven Reporting API 4.0.0-M12 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[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] (DOXIASITETOOLS-340) Rearrange title order in Velocity context
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847507#comment-17847507
]
ASF GitHub Bot commented on DOXIASITETOOLS-340:
---
michael-o opened a new pull request, #157:
URL: https://github.com/apache/maven-doxia-sitetools/pull/157
This closes #157
> Rearrange title order in Velocity context
> -
>
> Key: DOXIASITETOOLS-340
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-340
> Project: Maven Doxia Sitetools
> Issue Type: Dependency upgrade
> Components: Site renderer
>Affects Versions: 2.0.0-M18
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 2.0.0, 2.0.0-M19
>
>
> Currently, the title is set as follows:
> {projectName}} -- {{documentTitle}}
> This causes problems when you have multiple browsers tabs open, all you see
> is the project name not the document title, making is hard to identify. The
> common, today's approach is to go from specific to general: {{documentTitle}}
> -- {projectName}}. We should do the same.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [DOXIASITETOOLS-340] Rearrange title order in Velocity context [maven-doxia-sitetools]
michael-o opened a new pull request, #157: URL: https://github.com/apache/maven-doxia-sitetools/pull/157 This closes #157 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (DOXIASITETOOLS-340) Rearrange title order in Velocity context
Michael Osipov created DOXIASITETOOLS-340:
-
Summary: Rearrange title order in Velocity context
Key: DOXIASITETOOLS-340
URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-340
Project: Maven Doxia Sitetools
Issue Type: Dependency upgrade
Components: Site renderer
Affects Versions: 2.0.0-M18
Reporter: Michael Osipov
Assignee: Michael Osipov
Fix For: 2.0.0, 2.0.0-M19
Currently, the title is set as follows:
{projectName}} -- {{documentTitle}}
This causes problems when you have multiple browsers tabs open, all you see is
the project name not the document title, making is hard to identify. The
common, today's approach is to go from specific to general: {{documentTitle}}
-- {projectName}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DOXIASITETOOLS-340) Rearrange title order in Velocity context
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated DOXIASITETOOLS-340:
--
Description:
Currently, the title is set as follows:
{projectName}} -- {{documentTitle}}
This causes problems when you have multiple browsers tabs open, all you see is
the project name not the document title, making is hard to identify. The
common, today's approach is to go from specific to general: {{documentTitle}}
-- {projectName}}. We should do the same.
was:
Currently, the title is set as follows:
{projectName}} -- {{documentTitle}}
This causes problems when you have multiple browsers tabs open, all you see is
the project name not the document title, making is hard to identify. The
common, today's approach is to go from specific to general: {{documentTitle}}
-- {projectName}}
> Rearrange title order in Velocity context
> -
>
> Key: DOXIASITETOOLS-340
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-340
> Project: Maven Doxia Sitetools
> Issue Type: Dependency upgrade
> Components: Site renderer
>Affects Versions: 2.0.0-M18
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 2.0.0, 2.0.0-M19
>
>
> Currently, the title is set as follows:
> {projectName}} -- {{documentTitle}}
> This causes problems when you have multiple browsers tabs open, all you see
> is the project name not the document title, making is hard to identify. The
> common, today's approach is to go from specific to general: {{documentTitle}}
> -- {projectName}}. We should do the same.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1398) StringIndexOutOfBoundsException processing record classes
[
https://issues.apache.org/jira/browse/MSHARED-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847506#comment-17847506
]
Slawomir Jaranowski commented on MSHARED-1398:
--
[~jstehler] - fixed you can check my last commit to PR
> StringIndexOutOfBoundsException processing record classes
> -
>
> Key: MSHARED-1398
> URL: https://issues.apache.org/jira/browse/MSHARED-1398
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.14.0
>Reporter: Jared Stehler
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: maven-dependency-analyzer-next-release
>
>
> Processing classes with records results in an index out of bounds exception:
> {code:java}
> Caused by: java.lang.StringIndexOutOfBoundsException: Index 41 out of bounds
> for length 41
> at
> java.base@21.0.3/jdk.internal.util.Preconditions$1.apply(Preconditions.java:55)
> at
> java.base@21.0.3/jdk.internal.util.Preconditions$1.apply(Preconditions.java:52)
> at
> java.base@21.0.3/jdk.internal.util.Preconditions$4.apply(Preconditions.java:213)
> at
> java.base@21.0.3/jdk.internal.util.Preconditions$4.apply(Preconditions.java:210)
> at
> java.base@21.0.3/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:98)
> at
> java.base@21.0.3/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
> at
> java.base@21.0.3/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
> at java.base@21.0.3/java.lang.String.checkIndex(String.java:4832)
> at java.base@21.0.3/java.lang.StringLatin1.charAt(StringLatin1.java:46)
> at java.base@21.0.3/java.lang.String.charAt(String.java:1555)
> at app//org.objectweb.asm.Type.getReturnTypeOffset(Type.java:378)
> at app//org.objectweb.asm.Type.getReturnType(Type.java:355)
> at
> app//org.apache.maven.shared.dependency.analyzer.asm.ResultCollector.addMethodDesc(ResultCollector.java:112)
> {code}
> I have a reproducible test case here:
> https://github.com/jaredstehler/maven-dependency-analyzer/tree/js-repro-record-error
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MDEP-576) maven-dependency-plugin ignores class of object passed as a parameter to method references
[
https://issues.apache.org/jira/browse/MDEP-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MDEP-576:
-
Fix Version/s: 3.7.0
(was: waiting-for-feedback)
> maven-dependency-plugin ignores class of object passed as a parameter to
> method references
> --
>
> Key: MDEP-576
> URL: https://issues.apache.org/jira/browse/MDEP-576
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Vladimir Dergachev
>Priority: Minor
> Fix For: 3.7.0
>
>
> Hi there, i created a project on
> [github|https://github.com/vdergachev/dependency-plugin-vs-java-lambda] that
> can help you to reproduce the issue. Just clone it and make {code}mvn clean
> install{code}
> In my case plugin ignored Server class from jetty-server.jar and a as result
> i got message {code}Unused declared dependencies found{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MSHARED-1398) StringIndexOutOfBoundsException processing record classes
[
https://issues.apache.org/jira/browse/MSHARED-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski reassigned MSHARED-1398:
Assignee: Slawomir Jaranowski
> StringIndexOutOfBoundsException processing record classes
> -
>
> Key: MSHARED-1398
> URL: https://issues.apache.org/jira/browse/MSHARED-1398
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.14.0
>Reporter: Jared Stehler
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: maven-dependency-analyzer-next-release
>
>
> Processing classes with records results in an index out of bounds exception:
> {code:java}
> Caused by: java.lang.StringIndexOutOfBoundsException: Index 41 out of bounds
> for length 41
> at
> java.base@21.0.3/jdk.internal.util.Preconditions$1.apply(Preconditions.java:55)
> at
> java.base@21.0.3/jdk.internal.util.Preconditions$1.apply(Preconditions.java:52)
> at
> java.base@21.0.3/jdk.internal.util.Preconditions$4.apply(Preconditions.java:213)
> at
> java.base@21.0.3/jdk.internal.util.Preconditions$4.apply(Preconditions.java:210)
> at
> java.base@21.0.3/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:98)
> at
> java.base@21.0.3/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
> at
> java.base@21.0.3/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
> at java.base@21.0.3/java.lang.String.checkIndex(String.java:4832)
> at java.base@21.0.3/java.lang.StringLatin1.charAt(StringLatin1.java:46)
> at java.base@21.0.3/java.lang.String.charAt(String.java:1555)
> at app//org.objectweb.asm.Type.getReturnTypeOffset(Type.java:378)
> at app//org.objectweb.asm.Type.getReturnType(Type.java:355)
> at
> app//org.apache.maven.shared.dependency.analyzer.asm.ResultCollector.addMethodDesc(ResultCollector.java:112)
> {code}
> I have a reproducible test case here:
> https://github.com/jaredstehler/maven-dependency-analyzer/tree/js-repro-record-error
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MPLUGIN-524) "org.apache.maven.artifact.repository.metadata.Plugin.getPrefix() is null" with Nexus Staging plugin
Tristan Tarrant created MPLUGIN-524:
---
Summary:
"org.apache.maven.artifact.repository.metadata.Plugin.getPrefix() is null" with
Nexus Staging plugin
Key: MPLUGIN-524
URL: https://issues.apache.org/jira/browse/MPLUGIN-524
Project: Maven Plugin Tools
Issue Type: Bug
Components: Metadata Model
Affects Versions: 3.13.0
Reporter: Tristan Tarrant
While attempting to release a plugin with nexus-staging-maven-plugin, I get the
following exception:
{noformat}
[ERROR] Failed to execute goal
org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13:deploy
(injected-nexus-deploy) on project proto-schema-compatibility-maven-plugin:
Failed to update metadata org.infinispan.maven-plugins/maven-metadata.xml:
Cannot invoke "String.equals(Object)" because the return value of
"org.apache.maven.artifact.repository.metadata.Plugin.getPrefix()" is null ->
[Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13:deploy
(injected-nexus-deploy) on project proto-schema-compatibility-maven-plugin:
Failed to update metadata org.infinispan.maven-plugins/maven-metadata.xml:
Cannot invoke "String.equals(Object)" because the return value of
"org.apache.maven.artifact.repository.metadata.Plugin.getP refix()" is null
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:333)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:316)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:212)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:174)
at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
(MojoExecutor.java:75)
at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
(MojoExecutor.java:162)
at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
(DefaultMojosExecutionStrategy.java:39)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:159)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:105)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:73)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:53)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:118)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
(DirectMethodHandleAccessor.java:103)
at java.lang.reflect.Method.invoke (Method.java:580)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:283)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:226)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:407)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:348)
Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to update
metadata org.infinispan.maven-plugins/maven-metadata.xml: Cannot invoke
"String.equals(Object)" because the return value of
"org.apache.maven.artifact.repository.metadata.Plugin.getPrefix()" is null
at org.sonatype.nexus.maven.staging.deploy.DeployMojo.execute
(DeployMojo.java:216)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:126)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:328)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:316)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:212)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:174)
at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
(MojoExecutor.java:75)
at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
(MojoExecutor.java:162)
at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
(DefaultMojosExecutionStrategy.java:39)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:159)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:105)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:73)
at
Re: [PR] Add hint about mvnrepository.com [maven-site]
rmannibucau commented on PR #518: URL: https://github.com/apache/maven-site/pull/518#issuecomment-2118659597 It is not the only one so guess it is either we enable any to be on our website or none. Im for having them but mention their pitfalls (inaccurate results mainly) explicitly. If it helps, all good for users, else just ignore IMHO. Not worse than when the doc says to use a maven plugin, it stays a proposal but there are always better options for some people. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
