[jira] [Commented] (MWRAPPER-141) Use distribution type of existing Maven Wrapper by default
[
https://issues.apache.org/jira/browse/MWRAPPER-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847468#comment-17847468
]
ASF GitHub Bot commented on MWRAPPER-141:
-
breun opened a new pull request, #141:
URL: https://github.com/apache/maven-wrapper/pull/141
Uses `distributionType` from `.mvn/wrapper/maven-wrapper.properties` by
default, when present.
https://issues.apache.org/jira/browse/MWRAPPER-141
> Use distribution type of existing Maven Wrapper by default
> --
>
> Key: MWRAPPER-141
> URL: https://issues.apache.org/jira/browse/MWRAPPER-141
> Project: Maven Wrapper
> Issue Type: Improvement
> Components: Maven Wrapper Plugin
>Reporter: Nils Breunese
>Priority: Major
>
> It would be great if the {{wrapper:wrapper}} goal would use the type of an
> existing Maven Wrapper as the default, because this would allow making
> changes to the Maven version or other configuration, without having to
> specify the type of the existing Maven Wrapper again. This would be
> especially handy when changing (updating) the Maven version, or the Maven
> Wrapper version.
> This would also avoid accidentally changing the distribution type when a user
> forgets to specify the type of the existing Maven Wrapper.
> It should still be possible call {{wrapper:wrapper -Dtype=$type}} to
> explicitly set a different type for an existing project.
> When there is no existing Maven Wrapper, or when it exists but doesn't have
> {{distributionType}} set in {{{}maven-wrapper.properties{}}}, then the
> default {{only-script}} type should still be used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MWRAPPER-141) Use distribution type of existing Maven Wrapper by default
Nils Breunese created MWRAPPER-141:
--
Summary: Use distribution type of existing Maven Wrapper by default
Key: MWRAPPER-141
URL: https://issues.apache.org/jira/browse/MWRAPPER-141
Project: Maven Wrapper
Issue Type: Improvement
Components: Maven Wrapper Plugin
Reporter: Nils Breunese
It would be great if the {{wrapper:wrapper}} goal would use the type of an
existing Maven Wrapper as the default, because this would allow making changes
to the Maven version or other configuration, without having to specify the type
of the existing Maven Wrapper again. This would be especially handy when
changing (updating) the Maven version, or the Maven Wrapper version.
This would also avoid accidentally changing the distribution type when a user
forgets to specify the type of the existing Maven Wrapper.
It should still be possible call {{wrapper:wrapper -Dtype=$type}} to explicitly
set a different type for an existing project.
When there is no existing Maven Wrapper, or when it exists but doesn't have
{{distributionType}} set in {{{}maven-wrapper.properties{}}}, then the default
{{only-script}} type should still be used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Fix section indents [maven-site]
asfgit merged PR #528: URL: https://github.com/apache/maven-site/pull/528 -- 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=17847442#comment-17847442
]
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_r1605514887
##
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:
I probably need to pop the code open to figure this out. What is "buildJob"?
It's a org.apache.maven.plugins.invoker.model.BuildJob, right? If so, why does
it need escaped XML test instead of just plain text? I'd expect it to supply
unescaped strings to the writer which would then do any necessary escaping.
In line 1639 above, the message is not escaped. It should likely be escaped
in both or neither.
> 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
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_r1605514887
##
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:
I probably need to pop the code open to figure this out. What is "buildJob"?
It's a org.apache.maven.plugins.invoker.model.BuildJob, right? If so, why does
it need escaped XML test instead of just plain text? I'd expect it to supply
unescaped strings to the writer which would then do any necessary escaping.
In line 1639 above, the message is not escaped. It should likely be escaped
in both or neither.
--
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] [Comment Edited] (MSHARED-1399) Upgrade to Doxia 2.0.0-M12
[ https://issues.apache.org/jira/browse/MSHARED-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847440#comment-17847440 ] Michael Osipov edited comment on MSHARED-1399 at 5/17/24 8:18 PM: -- Fixed with [cda5232a8110073b81a071e07f2bd03a12598ecc|https://gitbox.apache.org/repos/asf?p=maven-reporting-api.git;a=commit;h=cda5232a8110073b81a071e07f2bd03a12598ecc]. was (Author: michael-o): Fixed with [9ef677cd1800f904b8269ce234a6d8074e1197b1|https://gitbox.apache.org/repos/asf?p=maven-reporting-api.git;a=commit;h=9ef677cd1800f904b8269ce234a6d8074e1197b1]. > Upgrade to Doxia 2.0.0-M12 > -- > > Key: MSHARED-1399 > URL: https://issues.apache.org/jira/browse/MSHARED-1399 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-reporting-api >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: maven-reporting-api-4.0.0, maven-reporting-api-4.0.0-M12 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHARED-1399) Upgrade to Doxia 2.0.0-M12
[ https://issues.apache.org/jira/browse/MSHARED-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSHARED-1399. --- Resolution: Fixed Fixed with [9ef677cd1800f904b8269ce234a6d8074e1197b1|https://gitbox.apache.org/repos/asf?p=maven-reporting-api.git;a=commit;h=9ef677cd1800f904b8269ce234a6d8074e1197b1]. > Upgrade to Doxia 2.0.0-M12 > -- > > Key: MSHARED-1399 > URL: https://issues.apache.org/jira/browse/MSHARED-1399 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-reporting-api >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: maven-reporting-api-4.0.0, maven-reporting-api-4.0.0-M12 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1399) Upgrade to Doxia 2.0.0-M12
Michael Osipov created MSHARED-1399: --- Summary: Upgrade to Doxia 2.0.0-M12 Key: MSHARED-1399 URL: https://issues.apache.org/jira/browse/MSHARED-1399 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-reporting-api Reporter: Michael Osipov Assignee: Michael Osipov Fix For: maven-reporting-api-4.0.0, maven-reporting-api-4.0.0-M12 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Add hint about mvnrepository.com [maven-site]
cstamas commented on PR #518: URL: https://github.com/apache/maven-site/pull/518#issuecomment-2118316806 Nevertheless, it offers unique service of searching in repositories no other service offer. Many of the Maven committers are using it as well, IMHO is completely okay to mention it on the Maven site. Consider maybe alt search engine? ;) -- 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] Add hint about mvnrepository.com [maven-site]
elharo commented on PR #518: URL: https://github.com/apache/maven-site/pull/518#issuecomment-2118312553 It's never the site I want to see, but it's always there at the top of the search results, more often than not ahead of the project site for whatever I'm actually looking for. Also, it's been a few years so details are fuzzy, but at a previous company/team/project I recall I frequently had to explain to customers that the problems they were seeing were because they were on mvnrepository.com instead of where they should have been. -- 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] Fix section indents [maven-site]
michael-o commented on PR #528: URL: https://github.com/apache/maven-site/pull/528#issuecomment-2118302642 @slawekjaranowski Are we good to merge this or you need more time to review? No issue, if so. -- 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] (DOXIA-737) [REGRESSION] Making EmitAnchorsForIndexableEntries by default does not extract document titles anymore
[
https://issues.apache.org/jira/browse/DOXIA-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847436#comment-17847436
]
ASF GitHub Bot commented on DOXIA-737:
--
asfgit closed pull request #214: [DOXIA-737] [REGRESSION] Making
EmitAnchorsForIndexableEntries by def…
URL: https://github.com/apache/maven-doxia/pull/214
> [REGRESSION] Making EmitAnchorsForIndexableEntries by default does not
> extract document titles anymore
> --
>
> Key: DOXIA-737
> URL: https://issues.apache.org/jira/browse/DOXIA-737
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.0-M11
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Blocker
> Fix For: 2.0.0, 2.0.0-M12
>
>
> While working on https://github.com/apache/maven-site/pull/525 the following
> happens:
> Title before:
> {project} -- {document}
> Title now:
> {project}
> The document title is not extracted from the document anymore.
> If I do the following:
> {noformat}
> diff --git
> a/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
>
> b/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
> index 544b6b9..b6a7d1d 100644
> ---
> a/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
> +++
> b/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
> @@ -330,7 +330,6 @@ public class DefaultSiteRenderer implements Renderer {
> if (!isConfigured) {
> // DOXIASITETOOLS-146 don't render comments from source
> markup
> parser.setEmitComments(false);
> -parser.setEmitAnchorsForIndexableEntries(true);
> }
> // TODO: DOXIA-111: the filter used here must be checked
> generally.
> {noformat}
> Everything works again. I bet that the {{SiteRendererSink}} does not work
> well with the new approach in Doxia.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (DOXIA-737) [REGRESSION] Making EmitAnchorsForIndexableEntries by default does not extract document titles anymore
[
https://issues.apache.org/jira/browse/DOXIA-737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed DOXIA-737.
Resolution: Fixed
Fixed with
[c35e61cf6119f67b992c80aa9a971a1eb6975a8d|https://gitbox.apache.org/repos/asf?p=maven-doxia.git;a=commit;h=c35e61cf6119f67b992c80aa9a971a1eb6975a8d].
> [REGRESSION] Making EmitAnchorsForIndexableEntries by default does not
> extract document titles anymore
> --
>
> Key: DOXIA-737
> URL: https://issues.apache.org/jira/browse/DOXIA-737
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.0-M11
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Blocker
> Fix For: 2.0.0, 2.0.0-M12
>
>
> While working on https://github.com/apache/maven-site/pull/525 the following
> happens:
> Title before:
> {project} -- {document}
> Title now:
> {project}
> The document title is not extracted from the document anymore.
> If I do the following:
> {noformat}
> diff --git
> a/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
>
> b/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
> index 544b6b9..b6a7d1d 100644
> ---
> a/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
> +++
> b/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
> @@ -330,7 +330,6 @@ public class DefaultSiteRenderer implements Renderer {
> if (!isConfigured) {
> // DOXIASITETOOLS-146 don't render comments from source
> markup
> parser.setEmitComments(false);
> -parser.setEmitAnchorsForIndexableEntries(true);
> }
> // TODO: DOXIA-111: the filter used here must be checked
> generally.
> {noformat}
> Everything works again. I bet that the {{SiteRendererSink}} does not work
> well with the new approach in Doxia.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIA-737] [REGRESSION] Making EmitAnchorsForIndexableEntries by def… [maven-doxia]
asfgit closed pull request #214: [DOXIA-737] [REGRESSION] Making EmitAnchorsForIndexableEntries by def… URL: https://github.com/apache/maven-doxia/pull/214 -- 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] (DOXIA-737) [REGRESSION] Making EmitAnchorsForIndexableEntries by default does not extract document titles anymore
[
https://issues.apache.org/jira/browse/DOXIA-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847434#comment-17847434
]
ASF GitHub Bot commented on DOXIA-737:
--
michael-o commented on PR #214:
URL: https://github.com/apache/maven-doxia/pull/214#issuecomment-2118257573
> The test should be in Doxia. But I won’t have time to look into this the
next two weeks. Should not block merging though
Thanks, I will go on otherwise it would block the entire release train. I
have one more improvement for Doxia Sitetools left.
> [REGRESSION] Making EmitAnchorsForIndexableEntries by default does not
> extract document titles anymore
> --
>
> Key: DOXIA-737
> URL: https://issues.apache.org/jira/browse/DOXIA-737
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.0-M11
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Blocker
> Fix For: 2.0.0, 2.0.0-M12
>
>
> While working on https://github.com/apache/maven-site/pull/525 the following
> happens:
> Title before:
> {project} -- {document}
> Title now:
> {project}
> The document title is not extracted from the document anymore.
> If I do the following:
> {noformat}
> diff --git
> a/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
>
> b/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
> index 544b6b9..b6a7d1d 100644
> ---
> a/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
> +++
> b/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
> @@ -330,7 +330,6 @@ public class DefaultSiteRenderer implements Renderer {
> if (!isConfigured) {
> // DOXIASITETOOLS-146 don't render comments from source
> markup
> parser.setEmitComments(false);
> -parser.setEmitAnchorsForIndexableEntries(true);
> }
> // TODO: DOXIA-111: the filter used here must be checked
> generally.
> {noformat}
> Everything works again. I bet that the {{SiteRendererSink}} does not work
> well with the new approach in Doxia.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIA-737] [REGRESSION] Making EmitAnchorsForIndexableEntries by def… [maven-doxia]
michael-o commented on PR #214: URL: https://github.com/apache/maven-doxia/pull/214#issuecomment-2118257573 > The test should be in Doxia. But I won’t have time to look into this the next two weeks. Should not block merging though Thanks, I will go on otherwise it would block the entire release train. I have one more improvement for Doxia Sitetools left. -- 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] (DOXIA-737) [REGRESSION] Making EmitAnchorsForIndexableEntries by default does not extract document titles anymore
[
https://issues.apache.org/jira/browse/DOXIA-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847433#comment-17847433
]
ASF GitHub Bot commented on DOXIA-737:
--
kwin commented on PR #214:
URL: https://github.com/apache/maven-doxia/pull/214#issuecomment-2118252244
The test should be in Doxia. But I won’t have time to look into this the
next two weeks. Should not block merging though
> [REGRESSION] Making EmitAnchorsForIndexableEntries by default does not
> extract document titles anymore
> --
>
> Key: DOXIA-737
> URL: https://issues.apache.org/jira/browse/DOXIA-737
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.0-M11
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Blocker
> Fix For: 2.0.0, 2.0.0-M12
>
>
> While working on https://github.com/apache/maven-site/pull/525 the following
> happens:
> Title before:
> {project} -- {document}
> Title now:
> {project}
> The document title is not extracted from the document anymore.
> If I do the following:
> {noformat}
> diff --git
> a/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
>
> b/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
> index 544b6b9..b6a7d1d 100644
> ---
> a/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
> +++
> b/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
> @@ -330,7 +330,6 @@ public class DefaultSiteRenderer implements Renderer {
> if (!isConfigured) {
> // DOXIASITETOOLS-146 don't render comments from source
> markup
> parser.setEmitComments(false);
> -parser.setEmitAnchorsForIndexableEntries(true);
> }
> // TODO: DOXIA-111: the filter used here must be checked
> generally.
> {noformat}
> Everything works again. I bet that the {{SiteRendererSink}} does not work
> well with the new approach in Doxia.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIA-737] [REGRESSION] Making EmitAnchorsForIndexableEntries by def… [maven-doxia]
kwin commented on PR #214: URL: https://github.com/apache/maven-doxia/pull/214#issuecomment-2118252244 The test should be in Doxia. But I won’t have time to look into this the next two weeks. Should not block merging though -- 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] (DOXIA-737) [REGRESSION] Making EmitAnchorsForIndexableEntries by default does not extract document titles anymore
[
https://issues.apache.org/jira/browse/DOXIA-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847432#comment-17847432
]
ASF GitHub Bot commented on DOXIA-737:
--
michael-o commented on PR #214:
URL: https://github.com/apache/maven-doxia/pull/214#issuecomment-2118249268
> Thanks for fixing this. Wondering though why there is no IT/UT having
caught that. Probably time to add one…
Do you have an idea from the top of your head? Took me some time to tackle
this. Don't whether it should be in Doxia or somewhere later this test.
> [REGRESSION] Making EmitAnchorsForIndexableEntries by default does not
> extract document titles anymore
> --
>
> Key: DOXIA-737
> URL: https://issues.apache.org/jira/browse/DOXIA-737
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.0-M11
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Blocker
> Fix For: 2.0.0, 2.0.0-M12
>
>
> While working on https://github.com/apache/maven-site/pull/525 the following
> happens:
> Title before:
> {project} -- {document}
> Title now:
> {project}
> The document title is not extracted from the document anymore.
> If I do the following:
> {noformat}
> diff --git
> a/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
>
> b/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
> index 544b6b9..b6a7d1d 100644
> ---
> a/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
> +++
> b/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
> @@ -330,7 +330,6 @@ public class DefaultSiteRenderer implements Renderer {
> if (!isConfigured) {
> // DOXIASITETOOLS-146 don't render comments from source
> markup
> parser.setEmitComments(false);
> -parser.setEmitAnchorsForIndexableEntries(true);
> }
> // TODO: DOXIA-111: the filter used here must be checked
> generally.
> {noformat}
> Everything works again. I bet that the {{SiteRendererSink}} does not work
> well with the new approach in Doxia.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-737) [REGRESSION] Making EmitAnchorsForIndexableEntries by default does not extract document titles anymore
[
https://issues.apache.org/jira/browse/DOXIA-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847430#comment-17847430
]
ASF GitHub Bot commented on DOXIA-737:
--
michael-o commented on PR #214:
URL: https://github.com/apache/maven-doxia/pull/214#issuecomment-2118248557
> BTW: There is no need for git commit messages which close the PR.. This is
only useful when referencing a GitHub issue.
I know, I do it on purpose to establish the connection between the commit
and the PR when browsing `git log` from the terminal. Metadata.
> [REGRESSION] Making EmitAnchorsForIndexableEntries by default does not
> extract document titles anymore
> --
>
> Key: DOXIA-737
> URL: https://issues.apache.org/jira/browse/DOXIA-737
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.0-M11
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Blocker
> Fix For: 2.0.0, 2.0.0-M12
>
>
> While working on https://github.com/apache/maven-site/pull/525 the following
> happens:
> Title before:
> {project} -- {document}
> Title now:
> {project}
> The document title is not extracted from the document anymore.
> If I do the following:
> {noformat}
> diff --git
> a/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
>
> b/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
> index 544b6b9..b6a7d1d 100644
> ---
> a/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
> +++
> b/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
> @@ -330,7 +330,6 @@ public class DefaultSiteRenderer implements Renderer {
> if (!isConfigured) {
> // DOXIASITETOOLS-146 don't render comments from source
> markup
> parser.setEmitComments(false);
> -parser.setEmitAnchorsForIndexableEntries(true);
> }
> // TODO: DOXIA-111: the filter used here must be checked
> generally.
> {noformat}
> Everything works again. I bet that the {{SiteRendererSink}} does not work
> well with the new approach in Doxia.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIA-737] [REGRESSION] Making EmitAnchorsForIndexableEntries by def… [maven-doxia]
michael-o commented on PR #214: URL: https://github.com/apache/maven-doxia/pull/214#issuecomment-2118249268 > Thanks for fixing this. Wondering though why there is no IT/UT having caught that. Probably time to add one… Do you have an idea from the top of your head? Took me some time to tackle this. Don't whether it should be in Doxia or somewhere later this test. -- 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] [DOXIA-737] [REGRESSION] Making EmitAnchorsForIndexableEntries by def… [maven-doxia]
michael-o commented on PR #214: URL: https://github.com/apache/maven-doxia/pull/214#issuecomment-2118248557 > BTW: There is no need for git commit messages which close the PR.. This is only useful when referencing a GitHub issue. I know, I do it on purpose to establish the connection between the commit and the PR when browsing `git log` from the terminal. Metadata. -- 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] (DOXIA-737) [REGRESSION] Making EmitAnchorsForIndexableEntries by default does not extract document titles anymore
[
https://issues.apache.org/jira/browse/DOXIA-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847429#comment-17847429
]
ASF GitHub Bot commented on DOXIA-737:
--
kwin commented on PR #214:
URL: https://github.com/apache/maven-doxia/pull/214#issuecomment-2118247607
BTW: There is no need for git commit messages which close the PR.. This is
only useful when referencing a GitHub issue.
> [REGRESSION] Making EmitAnchorsForIndexableEntries by default does not
> extract document titles anymore
> --
>
> Key: DOXIA-737
> URL: https://issues.apache.org/jira/browse/DOXIA-737
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.0-M11
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Blocker
> Fix For: 2.0.0, 2.0.0-M12
>
>
> While working on https://github.com/apache/maven-site/pull/525 the following
> happens:
> Title before:
> {project} -- {document}
> Title now:
> {project}
> The document title is not extracted from the document anymore.
> If I do the following:
> {noformat}
> diff --git
> a/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
>
> b/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
> index 544b6b9..b6a7d1d 100644
> ---
> a/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
> +++
> b/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
> @@ -330,7 +330,6 @@ public class DefaultSiteRenderer implements Renderer {
> if (!isConfigured) {
> // DOXIASITETOOLS-146 don't render comments from source
> markup
> parser.setEmitComments(false);
> -parser.setEmitAnchorsForIndexableEntries(true);
> }
> // TODO: DOXIA-111: the filter used here must be checked
> generally.
> {noformat}
> Everything works again. I bet that the {{SiteRendererSink}} does not work
> well with the new approach in Doxia.
--
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=17847428#comment-17847428
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118247404
Please also prepend:
https://docs.oracle.com/javase/7/docs/api/java/lang/Character.html#getName%28int%29
Then we know what we print out.
> 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
Re: [PR] [DOXIA-737] [REGRESSION] Making EmitAnchorsForIndexableEntries by def… [maven-doxia]
kwin commented on PR #214: URL: https://github.com/apache/maven-doxia/pull/214#issuecomment-2118247607 BTW: There is no need for git commit messages which close the PR.. This is only useful when referencing a GitHub 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
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-2118247404 Please also prepend: https://docs.oracle.com/javase/7/docs/api/java/lang/Character.html#getName%28int%29 Then we know what we print out. -- 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=17847426#comment-17847426
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118242573
@slawekjaranowski Please ping compiler and surefire plugin in the embedded
IT, that's the reason why there is no output.
> 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
>
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-2118242573 @slawekjaranowski Please ping compiler and surefire plugin in the embedded IT, that's the reason why there is no output. -- 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=17847425#comment-17847425
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118239187
@slawekjaranowski Just ran the changed IT with 3.8.8 and 3.9.6. In 3.8.8 I
don't see output from 0x00 to 0x0F at all in `build.log`. Regardless of the
escaping you applied. There is some inherent bug here which I prefer to
understand first because applying this change.
> 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
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-2118239187 @slawekjaranowski Just ran the changed IT with 3.8.8 and 3.9.6. In 3.8.8 I don't see output from 0x00 to 0x0F at all in `build.log`. Regardless of the escaping you applied. There is some inherent bug here which I prefer to understand first because applying this change. -- 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] Bump slf4jVersion from 2.0.11 to 2.0.13 [maven]
gnodet commented on PR #1519: URL: https://github.com/apache/maven/pull/1519#issuecomment-2118230655 @dependabot rebase -- 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] Fix distribution licenses [maven]
gnodet merged PR #1525: URL: https://github.com/apache/maven/pull/1525 -- 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] (MGPG-92) `--pinentry-mode error` cannot be used with gpg-agent "extra" socket
[
https://issues.apache.org/jira/browse/MGPG-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847418#comment-17847418
]
Tamas Cservenak commented on MGPG-92:
-
True, in case of HW device BouncyCastle signer will not help.
Am not quite educated with HW keys, could you maybe provide a PR or at least a
"hint" what should be modified to make it work for you?
> `--pinentry-mode error` cannot be used with gpg-agent "extra" socket
>
>
> Key: MGPG-92
> URL: https://issues.apache.org/jira/browse/MGPG-92
> Project: Maven GPG Plugin
> Issue Type: Bug
>Reporter: Nick Dimiduk
>Priority: Major
>
> Over on HBASE-27312, we found an issue in our release automation, which
> relies on using this plugin and a GnuPG agent for performing builds inside of
> an isolated environment. With GPG version >= 2.1, the plugin will make use of
> {{--pinentry-mode error}}. This feature appears to not be available using the
> "extra" gpg-agent socket. We had to "upgrade" to using the "standard" socket,
> which probably exposes more gpg features to the isolated environment than we
> would like.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MWRAPPER-135) Provide a reliable way to determine the Maven Wrapper type
[ https://issues.apache.org/jira/browse/MWRAPPER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MWRAPPER-135. Assignee: Tamas Cservenak Resolution: Fixed Thanks [~breun] > Provide a reliable way to determine the Maven Wrapper type > -- > > Key: MWRAPPER-135 > URL: https://issues.apache.org/jira/browse/MWRAPPER-135 > Project: Maven Wrapper > Issue Type: Task > Components: Maven Wrapper Plugin >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.3.2 > > > Just like MWRAPPER-134 but for type. I completely forgot about this. As this > way, tooling can figure out not only version but type (also for humans, just > peek at properties). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MWRAPPER-135) Provide a reliable way to determine the Maven Wrapper type
[ https://issues.apache.org/jira/browse/MWRAPPER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847414#comment-17847414 ] ASF GitHub Bot commented on MWRAPPER-135: - cstamas merged PR #140: URL: https://github.com/apache/maven-wrapper/pull/140 > Provide a reliable way to determine the Maven Wrapper type > -- > > Key: MWRAPPER-135 > URL: https://issues.apache.org/jira/browse/MWRAPPER-135 > Project: Maven Wrapper > Issue Type: Task > Components: Maven Wrapper Plugin >Reporter: Tamas Cservenak >Priority: Major > Fix For: 3.3.2 > > > Just like MWRAPPER-134 but for type. I completely forgot about this. As this > way, tooling can figure out not only version but type (also for humans, just > peek at properties). -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MWRAPPER-135] Provide a reliable way to determine the Maven Wrapper type [maven-wrapper]
cstamas merged PR #140: URL: https://github.com/apache/maven-wrapper/pull/140 -- 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] Just a 'bulk update' of dependencies [maven]
cstamas closed pull request #1512: Just a 'bulk update' of dependencies URL: https://github.com/apache/maven/pull/1512 -- 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] Just a 'bulk update' of dependencies [maven]
cstamas commented on PR #1512: URL: https://github.com/apache/maven/pull/1512#issuecomment-2118215708 Agreed -- 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=17847412#comment-17847412
]
Jared Stehler commented on MSHARED-1398:
created [https://github.com/apache/maven-dependency-analyzer/pull/121] with the
failing test
> 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
>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] (MSHARED-1398) StringIndexOutOfBoundsException processing record classes
[
https://issues.apache.org/jira/browse/MSHARED-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847411#comment-17847411
]
ASF GitHub Bot commented on MSHARED-1398:
-
jaredstehler opened a new pull request, #121:
URL: https://github.com/apache/maven-dependency-analyzer/pull/121
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/MSHARED) 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. Also be sure having selected the correct
component.
- [ ] Each commit in the pull request should have a meaningful subject line
and body.
- [ ] Format the pull request title like `[MSHARED-XXX] - Fixes bug in
ApproximateQuantiles`,
where you replace `MSHARED-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).
> 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
>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)
[PR] [MSHARED-1398] Test case for reproducing StringIndexOutOfBoundsException [maven-dependency-analyzer]
jaredstehler opened a new pull request, #121: URL: https://github.com/apache/maven-dependency-analyzer/pull/121 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/MSHARED) 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. Also be sure having selected the correct component. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MSHARED-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MSHARED-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] (MSHARED-1398) StringIndexOutOfBoundsException processing record classes
[
https://issues.apache.org/jira/browse/MSHARED-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847410#comment-17847410
]
Jared Stehler commented on MSHARED-1398:
I did create a repo for reporting to ASM:
[https://github.com/jaredstehler/asm-issues/blob/main/src/main/java/com/jaredstehler/scratch/asm/issues/InvalidTypeDescriptor.java]
> 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
>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=17847409#comment-17847409
]
Slawomir Jaranowski commented on MINVOKER-351:
--
Please look at test in my PR, I modified it a little then when was proposed in
attachment.
* remove JDK 11 reqirement
* pin used plugin version site and surefire
> 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
[jira] [Updated] (MSHARED-1398) StringIndexOutOfBoundsException processing record classes
[
https://issues.apache.org/jira/browse/MSHARED-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSHARED-1398:
Fix Version/s: (was: maven-dependency-analyzer-next-release)
> 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
>Priority: Major
>
> 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] (MSHARED-1398) StringIndexOutOfBoundsException processing record classes
[
https://issues.apache.org/jira/browse/MSHARED-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSHARED-1398:
Fix Version/s: maven-dependency-analyzer-next-release
> 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
>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] (MPLUGIN-384) Nexus Staging Plugin - incompatibility
[
https://issues.apache.org/jira/browse/MPLUGIN-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847406#comment-17847406
]
Slawomir Jaranowski commented on MPLUGIN-384:
-
[~tristan.tarr...@gmail.com] please open a new issue
> Nexus Staging Plugin - incompatibility
> --
>
> Key: MPLUGIN-384
> URL: https://issues.apache.org/jira/browse/MPLUGIN-384
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.6.2
> Environment: Windows 10 64-bit, Java 8 and 17, maven 3.8.1
>Reporter: Bob Marinier
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.6.4
>
>
> Version 3.6.1 of maven-plugin-plugin worked fine, but since updating to
> version 3.6.2, I get an NPE (tested with Java 8 and Java 17). I believe the
> error in both Java 8 and Java 17 is the same, but Java 17 gives a better
> message (see below).
> Even though it's the nexus-staging-maven-plugin that is complaining, the
> message implies that the maven-plugin-plugin is somehow failing to extract
> the prefix from the plugin. Going back to maven-plugin-plugin version 3.6.1
> fixes the issue.
> {noformat}
> [ERROR] Failed to execute goal
> org.sonatype.plugins:nexus-staging-maven-plugin:1.6.8:deploy
> (injected-nexus-deploy) on project my-maven-plugin: Failed to update metadata
> my.group.id/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.8:deploy
> (injected-nexus-deploy) on project my-maven-plugin: Failed to update metadata
> my.group.id/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.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:972)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to update
> metadata my.group.id/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:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
>
[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=17847405#comment-17847405
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118180697
> > Moving to draft because the IT is poorly designed.
>
> I hope you want to redesign proposed IT or you have any other hints how
should be done.
It is rather the conditions the IT comes into play. Please read my analysis
on the JIRA 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 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
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-2118180697 > > Moving to draft because the IT is poorly designed. > > I hope you want to redesign proposed IT or you have any other hints how should be done. It is rather the conditions the IT comes into play. Please read my analysis on the JIRA 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] (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=17847404#comment-17847404
]
Gili commented on MJAR-310:
---
If the bug is in plexus-utils, we should probably fix it there too because a
lot of other plugins depend on it. I would hate to have to file a separate bug
report for each one of them.
> [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] (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=17847401#comment-17847401
]
ASF GitHub Bot commented on MINVOKER-351:
-
slawekjaranowski commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118165742
> Moving to draft because the IT is poorly designed.
I hope you want to redesign proposed IT or you have any other hints how
should be done.
> 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,
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-2118165742 > Moving to draft because the IT is poorly designed. I hope you want to redesign proposed IT or you have any other hints how should be done. -- 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=17847398#comment-17847398
]
Michael Osipov commented on MINVOKER-351:
-
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
When I diff the build log with Maven 3.8.x:
{noformat}
---
T E S T S
---
Running example.minvoker351.ExampleTest
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
{noformat}
with 3.9.6:
{noformat}
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running example.minvoker351.ExampleTest
null
!
"
#
$
%
&
'
(
)
*
+
,
-
.
/
0
1
2
3
4
5
6
7
8
9
:
;
<
=
>
?
@
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
[
\
]
^
_
`
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
p
q
r
s
t
u
v
w
x
y
z
{
|
}
~
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.078 s
-- in example.minvoker351.ExampleTest
[INFO]
{noformat}
I have clearly to see this requires more analysis.
[~cstamas], do you remember that we had problems with Plexus Utils with XML
parsing it had regressions compared to 3.8.x. This could be yet another
regression.
I think we need understand the cause better before we can identify where to
apply a proper fix.
> 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
>
[jira] [Updated] (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 updated MSHARED-1398:
-
Fix Version/s: maven-dependency-analyzer-next-release
> 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
>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] (MSHARED-1398) StringIndexOutOfBoundsException processing record classes
[
https://issues.apache.org/jira/browse/MSHARED-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847396#comment-17847396
]
Slawomir Jaranowski commented on MSHARED-1398:
--
[~jstehler] please create a PR with your test
> 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
>Priority: Major
>
> 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=17847395#comment-17847395
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118154917
Moving to draft because the IT is poorly designed.
> 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.
> *
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-2118154917 Moving to draft because the IT is poorly designed. -- 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=17847394#comment-17847394
]
Slawomir Jaranowski commented on MSHARED-1398:
--
Thanks for reporting I was dropped a simply catch such exception in
[https://github.com/apache/maven-dependency-analyzer/pull/118]
But you can skip problematic classes from analizes
I will check where is the root of cause - maybe we should report in to ASM.
> 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
>Priority: Major
>
> 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] (MSHARED-1398) StringIndexOutOfBoundsException processing record classes
[
https://issues.apache.org/jira/browse/MSHARED-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847390#comment-17847390
]
Jared Stehler commented on MSHARED-1398:
The failing method is asm Type.getReturnType(String)
In my failing test case, desc is
{code:java}
"Lrecordinvokedynamic/RecordInvokeDynamic;"{code}
> 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
>Priority: Major
>
> 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] (MSHARED-1398) Error processing record classes
Jared Stehler created MSHARED-1398:
--
Summary: Error 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
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] (MSHARED-1398) StringIndexOutOfBoundsException processing record classes
[
https://issues.apache.org/jira/browse/MSHARED-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jared Stehler updated MSHARED-1398:
---
Summary: StringIndexOutOfBoundsException processing record classes (was:
Error processing record classes)
> 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
>Priority: Major
>
> 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] [Comment Edited] (MWRAPPER-135) Provide a reliable way to determine the Maven Wrapper type
[
https://issues.apache.org/jira/browse/MWRAPPER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847367#comment-17847367
]
Nils Breunese edited comment on MWRAPPER-135 at 5/17/24 4:53 PM:
-
Also, if {{wrapper:wrapper}} is run on a project that already contains this
property in {{maven-wrapper.properties}} (for instance when updating Maven
Wrapper), would it make sense to use this type by default when {{type}} is not
explicitly set via {{{}-Dtype={}}}? If so, I guess this can also be implemented
via a separate ticket.
was (Author: breun):
Also, if {{wrapper:wrapper}} is run on a project that already contains this
property in {{maven-wrapper.properties}} (to update Maven Wrapper), would it
make sense to use this type by default when {{type}} is not explicitly set via
{{{}-Dtype={}}}? If so, I guess this can also be implemented via a separate
ticket.
> Provide a reliable way to determine the Maven Wrapper type
> --
>
> Key: MWRAPPER-135
> URL: https://issues.apache.org/jira/browse/MWRAPPER-135
> Project: Maven Wrapper
> Issue Type: Task
> Components: Maven Wrapper Plugin
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 3.3.2
>
>
> Just like MWRAPPER-134 but for type. I completely forgot about this. As this
> way, tooling can figure out not only version but type (also for humans, just
> peek at properties).
--
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=17847368#comment-17847368
]
Mikkel Kjeldsen commented on MINVOKER-351:
--
[~michael-o], curious output. This is the expected output:
{noformat}
~ $ cd $(mktemp -d)
/tmp/tmp.0HU4NpMJCX $ wget --quiet
https://issues.apache.org/jira/secure/attachment/13068809/minvoker-351.tar.gz
/tmp/tmp.0HU4NpMJCX $ tar vxf minvoker-351.tar.gz
minvoker-351/
minvoker-351/pom.xml
minvoker-351/src/
minvoker-351/src/it/
minvoker-351/src/it/minvoker-351/
minvoker-351/src/it/minvoker-351/pom.xml
minvoker-351/src/it/minvoker-351/src/
minvoker-351/src/it/minvoker-351/src/test/
minvoker-351/src/it/minvoker-351/src/test/java/
minvoker-351/src/it/minvoker-351/src/test/java/example/
minvoker-351/src/it/minvoker-351/src/test/java/example/minvoker351/
minvoker-351/src/it/minvoker-351/src/test/java/example/minvoker351/ExampleTest.java
minvoker-351/src/it/minvoker-351/src/main/
minvoker-351/src/it/minvoker-351/src/main/java/
minvoker-351/src/it/minvoker-351/src/main/java/example/
minvoker-351/src/it/minvoker-351/src/main/java/example/minvoker351/
minvoker-351/src/it/minvoker-351/src/main/java/example/minvoker351/Example.java
/tmp/tmp.0HU4NpMJCX $ cd minvoker-351/
/tmp/tmp.0HU4NpMJCX/minvoker-351 $ mvn --version
Apache Maven 3.9.6
Maven home: /usr/share/maven
Java version: 21.0.2, vendor: N/A, runtime: /usr/lib64/jvm/java-21-openjdk-21
Default locale: en_DK, platform encoding: UTF-8
OS name: "linux", version: "5.14.21-150500.55.52-default", arch: "amd64",
family: "unix"
/tmp/tmp.0HU4NpMJCX/minvoker-351 $ mvn verify site
[INFO] Scanning for projects...
[INFO]
[INFO] --< example.minvoker351:minvoker-351 >--
[INFO] Building minvoker-351 1.0-SNAPSHOT
[INFO] from pom.xml
[INFO] [ jar ]-
[INFO]
[INFO] --- resources:3.3.1:resources (default-resources) @ minvoker-351 ---
[INFO] skip non existing resourceDirectory
/tmp/tmp.0HU4NpMJCX/minvoker-351/src/main/resources
[INFO]
[INFO] --- compiler:3.11.0:compile (default-compile) @ minvoker-351 ---
[INFO] No sources to compile
[INFO]
[INFO] --- resources:3.3.1:testResources (default-testResources) @ minvoker-351
---
[INFO] skip non existing resourceDirectory
/tmp/tmp.0HU4NpMJCX/minvoker-351/src/test/resources
[INFO]
[INFO] --- compiler:3.11.0:testCompile (default-testCompile) @ minvoker-351 ---
[INFO] No sources to compile
[INFO]
[INFO] --- surefire:3.2.2:test (default-test) @ minvoker-351 ---
[INFO] No tests to run.
[INFO]
[INFO] --- jar:3.3.0:jar (default-jar) @ minvoker-351 ---
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO] Building jar:
/tmp/tmp.0HU4NpMJCX/minvoker-351/target/minvoker-351-1.0-SNAPSHOT.jar
[INFO]
[INFO] --- invoker:3.6.1:install (integration-test) @ minvoker-351 ---
[INFO] Installing
/tmp/tmp.0HU4NpMJCX/minvoker-351/target/minvoker-351-1.0-SNAPSHOT.jar to
/tmp/tmp.0HU4NpMJCX/minvoker-351/target/local-repo/example/minvoker351/minvoker-351/1.0-SNAPSHOT/minvoker-351-1.0-SNAPSHOT.jar
[INFO] Installing /tmp/tmp.0HU4NpMJCX/minvoker-351/pom.xml to
/tmp/tmp.0HU4NpMJCX/minvoker-351/target/local-repo/example/minvoker351/minvoker-351/1.0-SNAPSHOT/minvoker-351-1.0-SNAPSHOT.pom
[INFO]
[INFO] --- invoker:3.6.1:run (integration-test) @ minvoker-351 ---
[INFO] Building: minvoker-351/pom.xml
[INFO] minvoker-351/pom.xml . SUCCESS
(6.021 s)
[INFO] -
[INFO] Build Summary:
[INFO] Passed: 1, Failed: 0, Errors: 0, Skipped: 0
[INFO] -
[INFO]
[INFO] --- site:3.12.1:site (default-site) @ minvoker-351 ---
[INFO] configuring report plugin
org.apache.maven.plugins:maven-project-info-reports-plugin:3.5.0
[INFO] 15 reports detected for maven-project-info-reports-plugin:3.5.0:
ci-management, dependencies, dependency-info, dependency-management,
distribution-management, index, issue-management, licenses, mailing-lists,
modules, plugin-management, plugins, scm, summary, team
[INFO] configuring report plugin
org.apache.maven.plugins:maven-surefire-report-plugin:3.2.5
[INFO] preparing maven-surefire-report-plugin:report report requires
'[surefire]test' forked phase execution
[INFO]
[INFO] >>> surefire-report:3.2.5:report > [surefire]test @ minvoker-351 >>>
[INFO]
[INFO] --- resources:3.3.1:resources (default-resources) @ minvoker-351 ---
[INFO] skip non existing resourceDirectory
/tmp/tmp.0HU4NpMJCX/minvoker-351/src/main/resources
[INFO]
[INFO] --- compiler:3.11.0:compile (default-compile) @ minvoker-351 ---
[INFO] No sources to compile
[INFO]
[INFO] --- resources:3.3.1:testResources (default-testResources) @ minvoker-351
---
[INFO] skip non existing resourceDirectory
/tmp/tmp.0HU4NpMJCX/minvoker-351/src/test/resources
[INFO]
[INFO] ---
[jira] [Comment Edited] (MWRAPPER-135) Provide a reliable way to determine the Maven Wrapper type
[
https://issues.apache.org/jira/browse/MWRAPPER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847367#comment-17847367
]
Nils Breunese edited comment on MWRAPPER-135 at 5/17/24 4:23 PM:
-
Also, if {{wrapper:wrapper}} is run on a project that already contains this
property in {{maven-wrapper.properties}} (to update Maven Wrapper), would it
make sense to use this type by default when {{type}} is not explicitly set via
{{{}-Dtype={}}}? If so, I guess this can also be implemented via a separate
ticket.
was (Author: breun):
Also, if {{wrapper:wrapper}} is run on a project that already contains this
property in {{maven-wrapper.properties}} (to update Maven Wrapper), would it
make sense to use this type by default when {{type}} is not explicitly set via
{{{}-Dtype={}}}?
> Provide a reliable way to determine the Maven Wrapper type
> --
>
> Key: MWRAPPER-135
> URL: https://issues.apache.org/jira/browse/MWRAPPER-135
> Project: Maven Wrapper
> Issue Type: Task
> Components: Maven Wrapper Plugin
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 3.3.2
>
>
> Just like MWRAPPER-134 but for type. I completely forgot about this. As this
> way, tooling can figure out not only version but type (also for humans, just
> peek at properties).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MWRAPPER-135) Provide a reliable way to determine the Maven Wrapper type
[
https://issues.apache.org/jira/browse/MWRAPPER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847367#comment-17847367
]
Nils Breunese edited comment on MWRAPPER-135 at 5/17/24 4:21 PM:
-
Also, if {{wrapper:wrapper}} is run on a project that already contains this
property in {{maven-wrapper.properties}} (to update Maven Wrapper), would it
make sense to use this type by default when {{type}} is not explicitly set via
{{{}-Dtype={}}}?
was (Author: breun):
Also, if {{wrapper:wrapper}} is run on a project that already contains this
property in {{{}maven-wrapper.properties{}}}(to update Maven Wrapper), would it
make sense to use this type by default when {{type}} is not explicitly set via
{{{}-Dtype={}}}?
> Provide a reliable way to determine the Maven Wrapper type
> --
>
> Key: MWRAPPER-135
> URL: https://issues.apache.org/jira/browse/MWRAPPER-135
> Project: Maven Wrapper
> Issue Type: Task
> Components: Maven Wrapper Plugin
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 3.3.2
>
>
> Just like MWRAPPER-134 but for type. I completely forgot about this. As this
> way, tooling can figure out not only version but type (also for humans, just
> peek at properties).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-135) Provide a reliable way to determine the Maven Wrapper type
[
https://issues.apache.org/jira/browse/MWRAPPER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847367#comment-17847367
]
Nils Breunese commented on MWRAPPER-135:
Also, if {{wrapper:wrapper}} is run on a project that already contains this
property in {{{}maven-wrapper.properties{}}}(to update Maven Wrapper), would it
make sense to use this type by default when {{type}} is not explicitly set via
{{{}-Dtype={}}}?
> Provide a reliable way to determine the Maven Wrapper type
> --
>
> Key: MWRAPPER-135
> URL: https://issues.apache.org/jira/browse/MWRAPPER-135
> Project: Maven Wrapper
> Issue Type: Task
> Components: Maven Wrapper Plugin
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 3.3.2
>
>
> Just like MWRAPPER-134 but for type. I completely forgot about this. As this
> way, tooling can figure out not only version but type (also for humans, just
> peek at properties).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-135) Provide a reliable way to determine the Maven Wrapper type
[
https://issues.apache.org/jira/browse/MWRAPPER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847365#comment-17847365
]
Nils Breunese commented on MWRAPPER-135:
[~cstamas] I've created a pull request for this feature. Currently the property
name is {{{}distributionType{}}}, because that is also what it is called in the
{{WrapperMojo}} class internally. Do you think that is the best name, or should
it maybe be {{{}wrapperType{}}}?
> Provide a reliable way to determine the Maven Wrapper type
> --
>
> Key: MWRAPPER-135
> URL: https://issues.apache.org/jira/browse/MWRAPPER-135
> Project: Maven Wrapper
> Issue Type: Task
> Components: Maven Wrapper Plugin
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 3.3.2
>
>
> Just like MWRAPPER-134 but for type. I completely forgot about this. As this
> way, tooling can figure out not only version but type (also for humans, just
> peek at properties).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-135) Provide a reliable way to determine the Maven Wrapper type
[ https://issues.apache.org/jira/browse/MWRAPPER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847364#comment-17847364 ] ASF GitHub Bot commented on MWRAPPER-135: - breun opened a new pull request, #140: URL: https://github.com/apache/maven-wrapper/pull/140 Adds `distributionType` to `maven-wrapper.properties`. https://issues.apache.org/jira/browse/MWRAPPER-135 > Provide a reliable way to determine the Maven Wrapper type > -- > > Key: MWRAPPER-135 > URL: https://issues.apache.org/jira/browse/MWRAPPER-135 > Project: Maven Wrapper > Issue Type: Task > Components: Maven Wrapper Plugin >Reporter: Tamas Cservenak >Priority: Major > Fix For: 3.3.2 > > > Just like MWRAPPER-134 but for type. I completely forgot about this. As this > way, tooling can figure out not only version but type (also for humans, just > peek at properties). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MPLUGIN-384) Nexus Staging Plugin - incompatibility
[
https://issues.apache.org/jira/browse/MPLUGIN-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847359#comment-17847359
]
Tristan Tarrant edited comment on MPLUGIN-384 at 5/17/24 3:54 PM:
--
This has started happening again with 3.13.0 (3.12.0 works fine). From reading
the above I suspect MPLUGIN-520 is to blame
was (Author: tristan.tarr...@gmail.com):
This has started happening again with 3.13.0 (3.12.0 works fine).
> Nexus Staging Plugin - incompatibility
> --
>
> Key: MPLUGIN-384
> URL: https://issues.apache.org/jira/browse/MPLUGIN-384
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.6.2
> Environment: Windows 10 64-bit, Java 8 and 17, maven 3.8.1
>Reporter: Bob Marinier
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.6.4
>
>
> Version 3.6.1 of maven-plugin-plugin worked fine, but since updating to
> version 3.6.2, I get an NPE (tested with Java 8 and Java 17). I believe the
> error in both Java 8 and Java 17 is the same, but Java 17 gives a better
> message (see below).
> Even though it's the nexus-staging-maven-plugin that is complaining, the
> message implies that the maven-plugin-plugin is somehow failing to extract
> the prefix from the plugin. Going back to maven-plugin-plugin version 3.6.1
> fixes the issue.
> {noformat}
> [ERROR] Failed to execute goal
> org.sonatype.plugins:nexus-staging-maven-plugin:1.6.8:deploy
> (injected-nexus-deploy) on project my-maven-plugin: Failed to update metadata
> my.group.id/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.8:deploy
> (injected-nexus-deploy) on project my-maven-plugin: Failed to update metadata
> my.group.id/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.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:972)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to update
> metadata my.group.id/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:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
[jira] [Commented] (MPLUGIN-384) Nexus Staging Plugin - incompatibility
[
https://issues.apache.org/jira/browse/MPLUGIN-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847359#comment-17847359
]
Tristan Tarrant commented on MPLUGIN-384:
-
This has started happening again with 3.13.0 (3.12.0 works fine).
> Nexus Staging Plugin - incompatibility
> --
>
> Key: MPLUGIN-384
> URL: https://issues.apache.org/jira/browse/MPLUGIN-384
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.6.2
> Environment: Windows 10 64-bit, Java 8 and 17, maven 3.8.1
>Reporter: Bob Marinier
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.6.4
>
>
> Version 3.6.1 of maven-plugin-plugin worked fine, but since updating to
> version 3.6.2, I get an NPE (tested with Java 8 and Java 17). I believe the
> error in both Java 8 and Java 17 is the same, but Java 17 gives a better
> message (see below).
> Even though it's the nexus-staging-maven-plugin that is complaining, the
> message implies that the maven-plugin-plugin is somehow failing to extract
> the prefix from the plugin. Going back to maven-plugin-plugin version 3.6.1
> fixes the issue.
> {noformat}
> [ERROR] Failed to execute goal
> org.sonatype.plugins:nexus-staging-maven-plugin:1.6.8:deploy
> (injected-nexus-deploy) on project my-maven-plugin: Failed to update metadata
> my.group.id/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.8:deploy
> (injected-nexus-deploy) on project my-maven-plugin: Failed to update metadata
> my.group.id/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.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:972)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to update
> metadata my.group.id/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:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
>
[jira] [Commented] (MGPG-92) `--pinentry-mode error` cannot be used with gpg-agent "extra" socket
[
https://issues.apache.org/jira/browse/MGPG-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847338#comment-17847338
]
Nick Dimiduk commented on MGPG-92:
--
I may be mistaken, but I think this is not possible when the signing material
is stored on a hardware device. In this case, there is no password that can be
provided, and the only option is forwarding the agent. Anyway, this use-case
where this came up is not an "isolated" environment, though it is jumping
through several hoops in order to sign in a container process running in a VM
on the localhost (i.e., Docker Desktop + MacOS).
> `--pinentry-mode error` cannot be used with gpg-agent "extra" socket
>
>
> Key: MGPG-92
> URL: https://issues.apache.org/jira/browse/MGPG-92
> Project: Maven GPG Plugin
> Issue Type: Bug
>Reporter: Nick Dimiduk
>Priority: Major
>
> Over on HBASE-27312, we found an issue in our release automation, which
> relies on using this plugin and a GnuPG agent for performing builds inside of
> an isolated environment. With GPG version >= 2.1, the plugin will make use of
> {{--pinentry-mode error}}. This feature appears to not be available using the
> "extra" gpg-agent socket. We had to "upgrade" to using the "standard" socket,
> which probably exposes more gpg features to the isolated environment than we
> would like.
--
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=17847328#comment-17847328
]
ASF GitHub Bot commented on MINVOKER-351:
-
slawekjaranowski commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2117684010
> > As we see root cause is in plexus-xml I know that using escapeXml10 is a
workaround here.
> > So what is your proposition to solve issue in m-invoker-p?
> > @michael-o @elharo
>
> Regardless of the fix or the flaw in Plexus XML I completely fail to
understand the supplied reprocuder in the JIRA issue.
Ok.
- we execute m-invoker-p for project `src/it/MINVOKER-351`
- m-invoker-p - execute a project
`src/it/MINVOKER-351/src/it/minvoker-351`
- in `src/it/MINVOKER-351/src/it/minvoker-351` we have a unit test
which print some special chars to build output
- m-invoker-p - collect output of
`src/it/MINVOKER-351/src/it/minvoker-351` and store in buildlog file
- m-invoker-p - generate a junit report with `systemOut` element which
contains body of buildlog file
- execute `site-plugin` with `surefire-report` to confirm that generated
junit reports are ok
> 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
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-2117684010 > > As we see root cause is in plexus-xml I know that using escapeXml10 is a workaround here. > > So what is your proposition to solve issue in m-invoker-p? > > @michael-o @elharo > > Regardless of the fix or the flaw in Plexus XML I completely fail to understand the supplied reprocuder in the JIRA issue. Ok. - we execute m-invoker-p for project `src/it/MINVOKER-351` - m-invoker-p - execute a project `src/it/MINVOKER-351/src/it/minvoker-351` - in `src/it/MINVOKER-351/src/it/minvoker-351` we have a unit test which print some special chars to build output - m-invoker-p - collect output of `src/it/MINVOKER-351/src/it/minvoker-351` and store in buildlog file - m-invoker-p - generate a junit report with `systemOut` element which contains body of buildlog file - execute `site-plugin` with `surefire-report` to confirm that generated junit reports are ok -- 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] (MDEP-799) improve mvn dependency:tree - add optional JSON output of the results
[ https://issues.apache.org/jira/browse/MDEP-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847326#comment-17847326 ] ASF GitHub Bot commented on MDEP-799: - LogFlames commented on PR #391: URL: https://github.com/apache/maven-dependency-plugin/pull/391#issuecomment-2117679372 CLA is now registered. > improve mvn dependency:tree - add optional JSON output of the results > - > > Key: MDEP-799 > URL: https://issues.apache.org/jira/browse/MDEP-799 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: tree >Reporter: Zhenxu Ke >Priority: Major > > I'd like to add an output type JSON, will open a pull request soon -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MDEP-799] tree: add optional output type json [maven-dependency-plugin]
LogFlames commented on PR #391: URL: https://github.com/apache/maven-dependency-plugin/pull/391#issuecomment-2117679372 CLA is now registered. -- 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=17847291#comment-17847291
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2117611998
> As we see root cause is in plexus-xml I know that using escapeXml10 is a
workaround here.
>
> So what is your proposition to solve issue in m-invoker-p?
>
> @michael-o @elharo
Regardless of the fix or the flaw in Plexus XML I completely fail to
understand the supplied reprocuder in the JIRA 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 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
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-2117611998 > As we see root cause is in plexus-xml I know that using escapeXml10 is a workaround here. > > So what is your proposition to solve issue in m-invoker-p? > > @michael-o @elharo Regardless of the fix or the flaw in Plexus XML I completely fail to understand the supplied reprocuder in the JIRA 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] [Comment Edited] (MWRAPPER-140) only-script Type does not honor MAVEN_USER_HOME
[
https://issues.apache.org/jira/browse/MWRAPPER-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847285#comment-17847285
]
Adrian Shum edited comment on MWRAPPER-140 at 5/17/24 1:25 PM:
---
{{Attached please find a quick fix I done myself.}}
I applied the same change of mvnw locally and seems working fine, but Windows
mvwn.cmd I have no way to test.
was (Author: adrianshum):
{{Following is a quick fix I done myself but I have just found that I am not
allowed to push changes and create pull requests.}}
I applied the same change of mvnw locally and seems working fine, but Windows
mvwn.cmd I have no way to test.
{{diff --git a/maven-wrapper-distribution/src/resources/only-mvnw
b/maven-wrapper-distribution/src/resources/only-mvnw}}
{{index b04e16b..dc12d6a 100755}}
{{--- a/maven-wrapper-distribution/src/resources/only-mvnw}}
{{+++ b/maven-wrapper-distribution/src/resources/only-mvnw}}
{{@@ -131,7 +131,8 @@ esac}}
{{ distributionUrlName="${distributionUrl##*/}"}}
{{ distributionUrlNameMain="${distributionUrlName%.*}"}}
{{ distributionUrlNameMain="${distributionUrlNameMain%-bin}"}}
{{-MAVEN_HOME="$HOME/.m2/wrapper/dists/${distributionUrlNameMain-}/$(hash_string
"$distributionUrl")"}}
{{+MAVEN_USER_HOME="${MAVEN_USER_HOME:-${HOME}/.m2}"}}
{{+MAVEN_HOME="${MAVEN_USER_HOME}/wrapper/dists/${distributionUrlNameMain-}/$(hash_string
"$distributionUrl")"}}
{{ }}
{{ exec_maven() {}}
{{ unset MVNW_VERBOSE MVNW_USERNAME MVNW_PASSWORD MVNW_REPOURL || :}}
{{diff --git a/maven-wrapper-distribution/src/resources/only-mvnw.cmd
b/maven-wrapper-distribution/src/resources/only-mvnw.cmd}}
{{index da5a302..d3e39f4 100644}}
{{--- a/maven-wrapper-distribution/src/resources/only-mvnw.cmd}}
{{+++ b/maven-wrapper-distribution/src/resources/only-mvnw.cmd}}
{{@@ -79,6 +79,9 @@ if ($env:MVNW_REPOURL) {}}
{{ $distributionUrlName = $distributionUrl -replace '^.*/',''}}
{{ $distributionUrlNameMain = $distributionUrlName -replace '\.[^.]*$',''
-replace '-bin$',''}}
{{ $MAVEN_HOME_PARENT = "$HOME/.m2/wrapper/dists/$distributionUrlNameMain"}}
{{+if ($env:MAVEN_USER_HOME) {}}
{{+ $MAVEN_HOME_PARENT =
"$env:MAVEN_USER_HOME/wrapper/dists/$distributionUrlNameMain"}}
{{+}}}
{{ $MAVEN_HOME_NAME =
([System.Security.Cryptography.MD5]::Create().ComputeHash([byte[]][char[]]$distributionUrl)
| ForEach-Object \{$_.ToString("x2")}) -join ''}}
{{ $MAVEN_HOME = "$MAVEN_HOME_PARENT/$MAVEN_HOME_NAME"}}
{{ }}
> only-script Type does not honor MAVEN_USER_HOME
> ---
>
> Key: MWRAPPER-140
> URL: https://issues.apache.org/jira/browse/MWRAPPER-140
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.3.1
>Reporter: Adrian Shum
>Priority: Major
> Attachments: patch
>
>
> As per described in [https://maven.apache.org/wrapper/index.html] we could
> set MAVEN_USER_HOME to define the location that Maven distro be downloaded to.
> For type=bin, it seems working as expected. However for type=script-only, it
> is trying to create director under ~/.m2 even I have MAVEN_USER_HOME set.
>
--
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=17847289#comment-17847289
]
Michael Osipov commented on MINVOKER-351:
-
[~mkjeldsen], beat me, but I don't see the failure:
{noformat}
D:\Entwicklung\Projekte\minvoker-351> mvn clean verify site
[INFO] Scanning for projects...
[INFO]
[INFO] --< example.minvoker351:minvoker-351 >--
[INFO] Building minvoker-351 1.0-SNAPSHOT
[INFO] from pom.xml
[INFO] [ jar ]-
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ minvoker-351 ---
[INFO] Deleting D:\Entwicklung\Projekte\minvoker-351\target
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
minvoker-351 ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
D:\Entwicklung\Projekte\minvoker-351\src\main\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ minvoker-351
---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
minvoker-351 ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
D:\Entwicklung\Projekte\minvoker-351\src\test\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @
minvoker-351 ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ minvoker-351 ---
[INFO] No tests to run.
[INFO]
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ minvoker-351 ---
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO] Building jar:
D:\Entwicklung\Projekte\minvoker-351\target\minvoker-351-1.0-SNAPSHOT.jar
[INFO]
[INFO] --- maven-invoker-plugin:3.6.1:install (integration-test) @ minvoker-351
---
[INFO] Installing
D:\Entwicklung\Projekte\minvoker-351\target\minvoker-351-1.0-SNAPSHOT.jar to
D:\Entwicklung\Projekte\minvoker-351\target\local-repo\example\minvoker351\minvoker-351\1.0-SNAPSHOT\minvoker-351-1.0-SNAPSHOT.jar
[INFO] Installing D:\Entwicklung\Projekte\minvoker-351\pom.xml to
D:\Entwicklung\Projekte\minvoker-351\target\local-repo\example\minvoker351\minvoker-351\1.0-SNAPSHOT\minvoker-351-1.0-SNAPSHOT.pom
[INFO]
[INFO] --- maven-invoker-plugin:3.6.1:run (integration-test) @ minvoker-351 ---
[INFO] Building: minvoker-351\pom.xml
[INFO] minvoker-351\pom.xml . SUCCESS
(15.12 s)
[INFO] -
[INFO] Build Summary:
[INFO] Passed: 1, Failed: 0, Errors: 0, Skipped: 0
[INFO] -
[INFO]
[INFO] --- maven-site-plugin:3.12.1:site (default-site) @ minvoker-351 ---
[INFO] configuring report plugin
org.apache.maven.plugins:maven-project-info-reports-plugin:3.5.0
[INFO] 15 reports detected for maven-project-info-reports-plugin:3.5.0:
ci-management, dependencies, dependency-info, dependency-management,
distribution-management, index, issue-management, licenses, mailing-lists,
modules, plugin-management, plugins, scm, summary, team
[INFO] configuring report plugin
org.apache.maven.plugins:maven-surefire-report-plugin:3.2.5
[INFO] preparing maven-surefire-report-plugin:report report requires
'[surefire]test' forked phase execution
[INFO]
[INFO] >>> maven-surefire-report-plugin:3.2.5:report > [surefire]test @
minvoker-351 >>>
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
minvoker-351 ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
D:\Entwicklung\Projekte\minvoker-351\src\main\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ minvoker-351
---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
minvoker-351 ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
D:\Entwicklung\Projekte\minvoker-351\src\test\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @
minvoker-351 ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ minvoker-351 ---
[INFO] No tests to run.
[INFO] Skipping execution of surefire because it has already been run for this
configuration
[INFO]
[INFO] <<< maven-surefire-report-plugin:3.2.5:report < [surefire]test @
minvoker-351 <<<
[INFO]
[INFO] '[surefire]test' forked phase execution for
maven-surefire-report-plugin:report report preparation done
[INFO] 3 reports detected for maven-surefire-report-plugin:3.2.5:
failsafe-report-only, report, report-only
[INFO] Rendering site with default locale English (en)
[WARNING] No project URL defined - decoration links will not be relativized!
[INFO] Rendering
[jira] [Updated] (MWRAPPER-140) only-script Type does not honor MAVEN_USER_HOME
[ https://issues.apache.org/jira/browse/MWRAPPER-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Shum updated MWRAPPER-140: - Attachment: patch > only-script Type does not honor MAVEN_USER_HOME > --- > > Key: MWRAPPER-140 > URL: https://issues.apache.org/jira/browse/MWRAPPER-140 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.3.1 >Reporter: Adrian Shum >Priority: Major > Attachments: patch > > > As per described in [https://maven.apache.org/wrapper/index.html] we could > set MAVEN_USER_HOME to define the location that Maven distro be downloaded to. > For type=bin, it seems working as expected. However for type=script-only, it > is trying to create director under ~/.m2 even I have MAVEN_USER_HOME set. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MWRAPPER-140) only-script Type does not honor MAVEN_USER_HOME
[
https://issues.apache.org/jira/browse/MWRAPPER-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847285#comment-17847285
]
Adrian Shum commented on MWRAPPER-140:
--
{{Following is a quick fix I done myself but I have just found that I am not
allowed to push changes and create pull requests.}}
I applied the same change of mvnw locally and seems working fine, but Windows
mvwn.cmd I have no way to test.
{{diff --git a/maven-wrapper-distribution/src/resources/only-mvnw
b/maven-wrapper-distribution/src/resources/only-mvnw}}
{{index b04e16b..dc12d6a 100755}}
{{--- a/maven-wrapper-distribution/src/resources/only-mvnw}}
{{+++ b/maven-wrapper-distribution/src/resources/only-mvnw}}
{{@@ -131,7 +131,8 @@ esac}}
{{ distributionUrlName="${distributionUrl##*/}"}}
{{ distributionUrlNameMain="${distributionUrlName%.*}"}}
{{ distributionUrlNameMain="${distributionUrlNameMain%-bin}"}}
{{-MAVEN_HOME="$HOME/.m2/wrapper/dists/${distributionUrlNameMain-}/$(hash_string
"$distributionUrl")"}}
{{+MAVEN_USER_HOME="${MAVEN_USER_HOME:-${HOME}/.m2}"}}
{{+MAVEN_HOME="${MAVEN_USER_HOME}/wrapper/dists/${distributionUrlNameMain-}/$(hash_string
"$distributionUrl")"}}
{{ }}
{{ exec_maven() {}}
{{ unset MVNW_VERBOSE MVNW_USERNAME MVNW_PASSWORD MVNW_REPOURL || :}}
{{diff --git a/maven-wrapper-distribution/src/resources/only-mvnw.cmd
b/maven-wrapper-distribution/src/resources/only-mvnw.cmd}}
{{index da5a302..d3e39f4 100644}}
{{--- a/maven-wrapper-distribution/src/resources/only-mvnw.cmd}}
{{+++ b/maven-wrapper-distribution/src/resources/only-mvnw.cmd}}
{{@@ -79,6 +79,9 @@ if ($env:MVNW_REPOURL) {}}
{{ $distributionUrlName = $distributionUrl -replace '^.*/',''}}
{{ $distributionUrlNameMain = $distributionUrlName -replace '\.[^.]*$',''
-replace '-bin$',''}}
{{ $MAVEN_HOME_PARENT = "$HOME/.m2/wrapper/dists/$distributionUrlNameMain"}}
{{+if ($env:MAVEN_USER_HOME) {}}
{{+ $MAVEN_HOME_PARENT =
"$env:MAVEN_USER_HOME/wrapper/dists/$distributionUrlNameMain"}}
{{+}}}
{{ $MAVEN_HOME_NAME =
([System.Security.Cryptography.MD5]::Create().ComputeHash([byte[]][char[]]$distributionUrl)
| ForEach-Object \{$_.ToString("x2")}) -join ''}}
{{ $MAVEN_HOME = "$MAVEN_HOME_PARENT/$MAVEN_HOME_NAME"}}
{{ }}
> only-script Type does not honor MAVEN_USER_HOME
> ---
>
> Key: MWRAPPER-140
> URL: https://issues.apache.org/jira/browse/MWRAPPER-140
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.3.1
>Reporter: Adrian Shum
>Priority: Major
>
> As per described in [https://maven.apache.org/wrapper/index.html] we could
> set MAVEN_USER_HOME to define the location that Maven distro be downloaded to.
> For type=bin, it seems working as expected. However for type=script-only, it
> is trying to create director under ~/.m2 even I have MAVEN_USER_HOME set.
>
--
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=17847278#comment-17847278
]
ASF GitHub Bot commented on MINVOKER-351:
-
slawekjaranowski commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2117538380
As we see root cause is in plexus-xml
I know that using escapeXml10 is a workaround here.
So what is your proposition to solve issue in m-invoker-p?
@michael-o @elharo
> 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
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-2117538380 As we see root cause is in plexus-xml I know that using escapeXml10 is a workaround here. So what is your proposition to solve issue in m-invoker-p? @michael-o @elharo -- 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-8123) Maven 4.0.0-beta-2 fails with maven-build-cache-extension 1.2.0
[
https://issues.apache.org/jira/browse/MNG-8123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847277#comment-17847277
]
ASF GitHub Bot commented on MNG-8123:
-
gnodet opened a new pull request, #1524:
URL: https://github.com/apache/maven/pull/1524
(no comment)
> Maven 4.0.0-beta-2 fails with maven-build-cache-extension 1.2.0
> ---
>
> Key: MNG-8123
> URL: https://issues.apache.org/jira/browse/MNG-8123
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-beta-2
>Reporter: Filipe Roque
>Priority: Major
>
> {code:java}
> ❯ mvn --version
> Apache Maven 4.0.0-beta-2 (828faba81940a8d2f2e5cfab6f60e35d1ab61ca0)
> Maven home: /opt/maven/apache-maven-4.0.0-beta-2
> Java version: 22.0.1, vendor: Eclipse Adoptium, runtime:
> /usr/lib/jvm/temurin-22-jdk-amd64
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "6.5.0-28-generic", arch: "amd64", family: "unix"
> {code}
> project created with
> {code:java}
> mvn archetype:generate {code}
> Adding maven cache extension
> {code:java}
> cat .mvn/extensions.xml
> http://maven.apache.org/EXTENSIONS/1.0.0;>
>
> org.apache.maven.extensions
> maven-build-cache-extension
> 1.2.0
>
>
> {code}
> Fails with:
> {code:java}
> ❯ mvn compile [INFO] Cache configuration is not available at configured path
> /home/froque/workspace/testes/project1/.mvn/maven-build-cache-config.xml,
> cache is enabled with defaults [INFO] Using XX hash algorithm for cache
> [ERROR] Internal error: com.google.inject.ProvisionException: Unable to
> provision, see the following errors: [ERROR] [ERROR] 1)
> [Guice/NullInjectedIntoNonNullable]: null returned by binding at
> LocatorWiring [ERROR] but the 3rd parameter of
> LifecyclePhasesHelper.(LifecyclePhasesHelper.java:61) is not @Nullable
> [ERROR] at LocatorWiring [ERROR] at
> LifecyclePhasesHelper.(LifecyclePhasesHelper.java:61) [ERROR] \_
> for 3rd parameter [ERROR] at
> ClassRealm[coreExtension>org.apache.maven.extensions:maven-build-cache-extension:1.2.0,
> parent: ClassRealm[plexus.core, parent: null]] [ERROR] \_ installed
> by: WireModule -> PlexusBindingModule [ERROR] at
> CacheControllerImpl.(CacheControllerImpl.java:156) [ERROR] \_ for
> 10th parameter [ERROR] at
> ClassRealm[coreExtension>org.apache.maven.extensions:maven-build-cache-extension:1.2.0,
> parent: ClassRealm[plexus.core, parent: null]] [ERROR] \_ installed
> by: WireModule -> PlexusBindingModule [ERROR] while locating
> CacheControllerImpl [ERROR] while locating Object annotated with * [ERROR]
> at LocatorWiring [ERROR] at
> CacheLifecycleParticipant.(CacheLifecycleParticipant.java:39) [ERROR]
> \_ for 2nd parameter [ERROR] at
> ClassRealm[coreExtension>org.apache.maven.extensions:maven-build-cache-extension:1.2.0,
> parent: ClassRealm[plexus.core, parent: null]] [ERROR] \_ installed
> by: WireModule -> PlexusBindingModule [ERROR] while locating
> CacheLifecycleParticipant [ERROR] while locating Object annotated with *
> [ERROR] [ERROR] Learn more: [ERROR]
> https://github.com/google/guice/wiki/NULL_INJECTED_INTO_NON_NULLABLE [ERROR]
> [ERROR] 1 error [ERROR] [ERROR] == [ERROR] Full
> classname legend: [ERROR] == [ERROR] CacheControllerImpl:
> "org.apache.maven.buildcache.CacheControllerImpl" [ERROR]
> CacheLifecycleParticipant:
> "org.apache.maven.buildcache.CacheLifecycleParticipant" [ERROR]
> LifecyclePhasesHelper:
> "org.apache.maven.buildcache.LifecyclePhasesHelper" [ERROR] LocatorWiring:
> "org.eclipse.sisu.wire.LocatorWiring" [ERROR] PlexusBindingModule:
> "org.eclipse.sisu.plexus.PlexusBindingModule" [ERROR] WireModule:
> "org.eclipse.sisu.wire.WireModule" [ERROR]
> [ERROR] End of classname legend: [ERROR] [ERROR] ->
> [Help 1] org.apache.maven.InternalErrorException: Internal error:
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:1) [Guice/NullInjectedIntoNonNullable]: null returned by binding at
> LocatorWiring but the 3rd parameter of
> LifecyclePhasesHelper.(LifecyclePhasesHelper.java:61) is not @Nullable
> at LocatorWiring at
> LifecyclePhasesHelper.(LifecyclePhasesHelper.java:61) \_ for 3rd
> parameter at
> ClassRealm[coreExtension>org.apache.maven.extensions:maven-build-cache-extension:1.2.0,
> parent: ClassRealm[plexus.core, parent: null]] \_ installed by:
> WireModule -> PlexusBindingModule at
> CacheControllerImpl.(CacheControllerImpl.java:156) \_ for 10th
> parameter at
>
[PR] [MNG-8123] Fix Lifecycle in v3 [maven]
gnodet opened a new pull request, #1524: URL: https://github.com/apache/maven/pull/1524 (no comment) -- 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] (MBUILDCACHE-78) Maven reactor doesn't work well for a multimodule project when enabling build cache
[
https://issues.apache.org/jira/browse/MBUILDCACHE-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847275#comment-17847275
]
Hongxin Liang commented on MBUILDCACHE-78:
--
I could still produce these two using 1.2.0 version.
For 1, I got this log:
{code:java}
[INFO] --< io.honnix:cache >---
[INFO] Building cache 1.0-SNAPSHOT[1/3]
[INFO] from pom.xml
[INFO] [ pom ]-
[INFO]
[INFO] < io.honnix:a >-
[INFO] Building a 1.0-SNAPSHOT[2/3]
[INFO] from a/pom.xml
[INFO] [ jar ]-
[INFO] Loading cache configuration from
/Users/honnix/Developer/github/cache/.mvn/maven-build-cache-config.xml
[INFO] Using SHA-256 hash algorithm for cache
[INFO] Going to calculate checksum for project [groupId=io.honnix, artifactId=a]
[INFO] Scanning plugins configurations to find input files. Probing is enabled,
values will be checked for presence in file system
[INFO] Found 1 input files. Project dir processing: 1, plugins: 1 millis
[INFO] Project inputs calculated in 3 ms. SHA-256 checksum
[d94bcab16e7817cbb356a288016b80130c30e87d3c0e96f63347697334c206f5] calculated
in 1 ms.
[INFO] Attempting to restore project io.honnix:a from build cache
[INFO] Local build found by checksum
d94bcab16e7817cbb356a288016b80130c30e87d3c0e96f63347697334c206f5
[INFO] Found cached build, restoring io.honnix:a from cache by checksum
d94bcab16e7817cbb356a288016b80130c30e87d3c0e96f63347697334c206f5
[INFO] Skipping plugin execution (cached): resources:resources
[INFO] Skipping plugin execution (cached): compiler:compile
[INFO]
[INFO] < io.honnix:b >-
[INFO] Building b 1.0-SNAPSHOT[3/3]
[INFO] from b/pom.xml
[INFO] [ jar ]-
[INFO] Going to calculate checksum for project [groupId=io.honnix, artifactId=b]
[INFO] Scanning plugins configurations to find input files. Probing is enabled,
values will be checked for presence in file system
[INFO] Found 1 input files. Project dir processing: 1, plugins: 1 millis
[INFO] Going to calculate checksum for project [groupId=io.honnix, artifactId=a]
[INFO] Project inputs calculated in 2 ms. SHA-256 checksum
[8a63d23bd4e2fb7162d1e6ef5d415a8b35527fc13c1b58122e2af25f52d53de0] calculated
in 0 ms.
[INFO] Attempting to restore project io.honnix:b from build cache
[INFO] Local build was not found by checksum
8a63d23bd4e2fb7162d1e6ef5d415a8b35527fc13c1b58122e2af25f52d53de0 for io.honnix:b
[INFO] Downloading from repo: ...
[INFO] Downloading from repo: ...
[INFO]
[INFO] Reactor Summary for cache 1.0-SNAPSHOT:
[INFO]
[INFO] cache .. SUCCESS [ 0.000 s]
[INFO] a .. SUCCESS [ 0.012 s]
[INFO] b .. FAILURE [ 16.822 s]
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 16.845 s (Wall Clock)
[INFO] Finished at: 2024-05-17T14:34:19+02:00
[INFO]
[ERROR] Failed to execute goal on project b: Could not resolve dependencies for
project io.honnix:b:jar:1.0-SNAPSHOT: The following artifacts could not be
resolved: io.honnix:a:jar:1.0-SNAPSHOT (absent): Could not find artifact
io.honnix:a:jar:1.0-SNAPSHOT in repo (...) -> [Help 1]
{code}
For 2, I got this log:
{code:java}
$ mvn compile
[INFO] Scanning for projects...
[INFO] BuildTimeEventSpy is registered.
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] cache [pom]
[INFO] a [jar]
[INFO] b [jar]
[INFO]
[INFO] Using the SmartBuilder implementation with a thread count of 11
[INFO]
[INFO] --< io.honnix:cache >---
[INFO] Building cache 1.0-SNAPSHOT[1/3]
[INFO] from pom.xml
[INFO] [ pom ]-
[INFO]
[INFO] < io.honnix:a >-
[INFO] Building a 1.0-SNAPSHOT[2/3]
[INFO] from a/pom.xml
[INFO]
[PR] Bump org.codehaus.plexus:plexus-interpolation from 1.26 to 1.27 [maven]
dependabot[bot] opened a new pull request, #1523: URL: https://github.com/apache/maven/pull/1523 Bumps [org.codehaus.plexus:plexus-interpolation](https://github.com/codehaus-plexus/plexus-interpolation) from 1.26 to 1.27. Release notes Sourced from https://github.com/codehaus-plexus/plexus-interpolation/releases;>org.codehaus.plexus:plexus-interpolation's releases. 1.27.0 New features and improvements Added support for PPC64LE (https://redirect.github.com/codehaus-plexus/plexus-interpolation/pull/25;>#25) https://github.com/ezeeyahoo;>@ezeeyahoo Add dependabot and release drafter configuration (https://redirect.github.com/codehaus-plexus/plexus-interpolation/pull/26;>#26) https://github.com/olamy;>@olamy Move to Junit5 (https://redirect.github.com/codehaus-plexus/plexus-interpolation/pull/64;>#64) https://github.com/slachiewicz;>@slachiewicz Dependency updates Bump plexus from 7 to 16 Bump maven-bundle-plugin from 3.0.1 to 5.1.9 Build use shared gh action (https://redirect.github.com/codehaus-plexus/plexus-interpolation/pull/57;>#57) https://github.com/olamy;>@olamy Reuse plexus-pom action for CI (https://redirect.github.com/codehaus-plexus/plexus-interpolation/pull/70;>#70) https://github.com/slachiewicz;>@slachiewicz Commits https://github.com/codehaus-plexus/plexus-interpolation/commit/f44266e74556c30fddcae4b20ee477e7e64a5204;>f44266e [maven-release-plugin] prepare release plexus-interpolation-1.27 https://github.com/codehaus-plexus/plexus-interpolation/commit/10d6389ad22ac8db8ee7279407d10d64295dc9ec;>10d6389 Bump org.codehaus.plexus:plexus from 15 to 16 https://github.com/codehaus-plexus/plexus-interpolation/commit/88f5a941f5b2c6ce5c60ba7b7d2c93a725206807;>88f5a94 Reuse plexus-pom action for CI https://github.com/codehaus-plexus/plexus-interpolation/commit/e980e6679d28afc3d0ccc067fb855ab1270ea97f;>e980e66 Bump org.codehaus.plexus:plexus from 14 to 15 https://github.com/codehaus-plexus/plexus-interpolation/commit/acb47031ead222f1bebb983d289907f97cbbe3c6;>acb4703 Reformat code https://github.com/codehaus-plexus/plexus-interpolation/commit/df44d880bda41f5d428835597dd47c0b1f3b2ba5;>df44d88 Bump org.codehaus.plexus:plexus from 11 to 14 https://github.com/codehaus-plexus/plexus-interpolation/commit/22b9c9b64132deb3b002f3f68d6b2d9034fc0d0e;>22b9c9b Bump maven-bundle-plugin from 5.1.8 to 5.1.9 https://github.com/codehaus-plexus/plexus-interpolation/commit/dad9f189b5c8782be76afaaa12b9c5a263cdcb95;>dad9f18 Move to Junit5 https://github.com/codehaus-plexus/plexus-interpolation/commit/f541b1aa9eda8a977967364e0b34b88d7a60dc73;>f541b1a Bump plexus from 10 to 11 https://github.com/codehaus-plexus/plexus-interpolation/commit/a2b39e67f33060f50e6d68349e5577bc114eafed;>a2b39e6 Bump maven-bundle-plugin from 5.1.7 to 5.1.8 Additional commits viewable in https://github.com/codehaus-plexus/plexus-interpolation/compare/plexus-interpolation-1.26...plexus-interpolation-1.27;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless
[PR] Bump slf4jVersion from 2.0.11 to 2.0.13 [maven]
dependabot[bot] opened a new pull request, #1519: URL: https://github.com/apache/maven/pull/1519 Bumps `slf4jVersion` from 2.0.11 to 2.0.13. Updates `org.slf4j:slf4j-api` from 2.0.11 to 2.0.13 Updates `org.slf4j:slf4j-simple` from 2.0.11 to 2.0.13 Updates `org.slf4j:jcl-over-slf4j` from 2.0.11 to 2.0.13 Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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
[PR] Bump com.fasterxml.woodstox:woodstox-core from 6.5.1 to 6.6.2 [maven]
dependabot[bot] opened a new pull request, #1518: URL: https://github.com/apache/maven/pull/1518 Bumps [com.fasterxml.woodstox:woodstox-core](https://github.com/FasterXML/woodstox) from 6.5.1 to 6.6.2. Commits https://github.com/FasterXML/woodstox/commit/3bed26213d3446e50408a2f10f8eabf5219c9035;>3bed262 [maven-release-plugin] prepare release woodstox-core-6.6.2 https://github.com/FasterXML/woodstox/commit/06dfc28437aed9a4c850e0b03c002bb5e1781daa;>06dfc28 Update release notes wrt https://redirect.github.com/FasterXML/woodstox/issues/200;>#200 https://github.com/FasterXML/woodstox/commit/d4431712fba049843cbb55031543d9b5a7b16236;>d443171 Fix shading of isorelax (https://redirect.github.com/FasterXML/woodstox/issues/200;>#200). (https://redirect.github.com/FasterXML/woodstox/issues/202;>#202) https://github.com/FasterXML/woodstox/commit/ef10fdca71b298d3a20bdb7434e68e0e798a6812;>ef10fdc Fix indentation of test class (remove tabs) https://github.com/FasterXML/woodstox/commit/4a256472344435d4fd6954298753b7fea68d1f44;>4a25647 Update oss-parent ref https://github.com/FasterXML/woodstox/commit/85551aa596515a5689c8c892cfa8a25425ea3440;>85551aa [maven-release-plugin] prepare for next development iteration https://github.com/FasterXML/woodstox/commit/03ab814e73d8dc6c40aaaea33625b6ca4431f9fe;>03ab814 [maven-release-plugin] prepare release woodstox-core-6.6.1 https://github.com/FasterXML/woodstox/commit/5a263999379f5c23eae84416c56ffc055b2a0165;>5a26399 Try resolve https://redirect.github.com/FasterXML/woodstox/issues/193;>#193: exclude refs to shaded modules (https://redirect.github.com/FasterXML/woodstox/issues/198;>#198) https://github.com/FasterXML/woodstox/commit/49a29244d566506fef58b947ef0edac0dabaa578;>49a2924 ... https://github.com/FasterXML/woodstox/commit/35c687d26618e5214167c10f7f01ed6b699f53cf;>35c687d Minor improvement to SimpleOutputElement.getName() Additional commits viewable in https://github.com/FasterXML/woodstox/compare/woodstox-core-6.5.1...woodstox-core-6.6.2;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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
[PR] Bump org.codehaus.plexus:plexus-cipher from 2.0 to 2.1.0 [maven]
dependabot[bot] opened a new pull request, #1517: URL: https://github.com/apache/maven/pull/1517 Bumps [org.codehaus.plexus:plexus-cipher](https://github.com/codehaus-plexus/plexus-cipher) from 2.0 to 2.1.0. Release notes Sourced from https://github.com/codehaus-plexus/plexus-cipher/releases;>org.codehaus.plexus:plexus-cipher's releases. 2.1.0 Switch to java.util.Base64 (https://redirect.github.com/codehaus-plexus/plexus-cipher/pull/35;>#35) https://github.com/slachiewicz;>@slachiewicz Move code to Java 8 (https://redirect.github.com/codehaus-plexus/plexus-cipher/pull/31;>#31) https://github.com/slachiewicz;>@slachiewicz Fixed insecure cryptography in PBECipher.java (https://redirect.github.com/codehaus-plexus/plexus-cipher/pull/23;>#23) https://github.com/gL1nt;>@gL1nt Bug Fixes Enable missed decryption test and adjust to new algorithm after https://redirect.github.com/codehaus-plexus/plexus-cipher/issues/23;>#23 (https://redirect.github.com/codehaus-plexus/plexus-cipher/pull/34;>#34) https://github.com/slachiewicz;>@slachiewicz Dependency updates Bump org.codehaus.plexus:plexus from 15 to 16 (https://redirect.github.com/codehaus-plexus/plexus-cipher/pull/41;>#41) https://github.com/dependabot;>@dependabot Move tests to JUnit 5 (https://redirect.github.com/codehaus-plexus/plexus-cipher/pull/39;>#39) https://github.com/slachiewicz;>@slachiewicz Bump org.codehaus.plexus:plexus from 14 to 15 (https://redirect.github.com/codehaus-plexus/plexus-cipher/pull/38;>#38) https://github.com/dependabot;>@dependabot Bump actions/checkout from 3 to 4 (https://redirect.github.com/codehaus-plexus/plexus-cipher/pull/37;>#37) https://github.com/dependabot;>@dependabot Bump org.codehaus.plexus:plexus from 10 to 14 (https://redirect.github.com/codehaus-plexus/plexus-cipher/pull/32;>#32) https://github.com/dependabot;>@dependabot Bump maven-surefire-plugin from 3.0.0 to 3.1.2 (https://redirect.github.com/codehaus-plexus/plexus-cipher/pull/30;>#30) https://github.com/dependabot;>@dependabot Bump maven-surefire-plugin from 2.22.2 to 3.0.0 (https://redirect.github.com/codehaus-plexus/plexus-cipher/pull/24;>#24) https://github.com/dependabot;>@dependabot Bump plexus from 8 to 10 (https://redirect.github.com/codehaus-plexus/plexus-cipher/pull/22;>#22) https://github.com/dependabot;>@dependabot Bump actions/checkout from 2 to 3 (https://redirect.github.com/codehaus-plexus/plexus-cipher/pull/13;>#13) https://github.com/dependabot;>@dependabot Bump release-drafter/release-drafter from 5.18.0 to 5.19.0 (https://redirect.github.com/codehaus-plexus/plexus-cipher/pull/14;>#14) https://github.com/dependabot;>@dependabot Bump actions/cache from 2 to 3.0.1 (https://redirect.github.com/codehaus-plexus/plexus-cipher/pull/16;>#16) https://github.com/dependabot;>@dependabot Bump actions/setup-java from 2 to 3 (https://redirect.github.com/codehaus-plexus/plexus-cipher/pull/17;>#17) https://github.com/dependabot;>@dependabot Bump github/codeql-action from 1 to 2 (https://redirect.github.com/codehaus-plexus/plexus-cipher/pull/18;>#18) https://github.com/dependabot;>@dependabot Bump release-drafter/release-drafter from 5.17.6 to 5.18.0 (https://redirect.github.com/codehaus-plexus/plexus-cipher/pull/11;>#11) https://github.com/dependabot;>@dependabot Bump release-drafter/release-drafter from 5.15.0 to 5.17.6 (https://redirect.github.com/codehaus-plexus/plexus-cipher/pull/10;>#10) https://github.com/dependabot;>@dependabot Bump sisuVersion from 0.3.4 to 0.3.5 (https://redirect.github.com/codehaus-plexus/plexus-cipher/pull/7;>#7) https://github.com/dependabot;>@dependabot Maintenance Reuse plexus-pom action for CI (https://redirect.github.com/codehaus-plexus/plexus-cipher/pull/40;>#40) https://github.com/slachiewicz;>@slachiewicz Move tests to JUnit 5 (https://redirect.github.com/codehaus-plexus/plexus-cipher/pull/39;>#39) https://github.com/slachiewicz;>@slachiewicz Quick fix reported issues in code style (https://redirect.github.com/codehaus-plexus/plexus-cipher/pull/33;>#33) https://github.com/slachiewicz;>@slachiewicz Build use shared actions (https://redirect.github.com/codehaus-plexus/plexus-cipher/pull/21;>#21) https://github.com/olamy;>@olamy Commits https://github.com/codehaus-plexus/plexus-cipher/commit/9c9613bc383f1465c9b2a8ec1c02a5152fb13298;>9c9613b [maven-release-plugin] prepare release plexus-cipher-2.1.0 https://github.com/codehaus-plexus/plexus-cipher/commit/8017c9e88fd512e0a96c073585887f067e6dd9c0;>8017c9e Move tests to JUnit 5 https://github.com/codehaus-plexus/plexus-cipher/commit/0e6e693e433de9b1988fad2170f407230b6e6f30;>0e6e693 Cleanup after parent pom update https://github.com/codehaus-plexus/plexus-cipher/commit/931a35bc74ade42810de0e77120de858f3c64285;>931a35b Bump
[PR] Bump org.codehaus.plexus:plexus-classworlds from 2.6.0 to 2.8.0 [maven]
dependabot[bot] opened a new pull request, #1522: URL: https://github.com/apache/maven/pull/1522 Bumps [org.codehaus.plexus:plexus-classworlds](https://github.com/codehaus-plexus/plexus-classworlds) from 2.6.0 to 2.8.0. Release notes Sourced from https://github.com/codehaus-plexus/plexus-classworlds/releases;>org.codehaus.plexus:plexus-classworlds's releases. 2.8.0 pom.mxl and site.xml cleanup (https://redirect.github.com/codehaus-plexus/plexus-classworlds/pull/95;>#95) https://github.com/hboutemy;>@hboutemy Dependency updates Migrate to JUnit 5 (https://redirect.github.com/codehaus-plexus/plexus-classworlds/pull/86;>#86) https://github.com/slachiewicz;>@slachiewicz Update dependencies used in test to more recent ones with less CVE (https://redirect.github.com/codehaus-plexus/plexus-classworlds/pull/88;>#88) https://github.com/slachiewicz;>@slachiewicz Maintenance Reuse plexus-pom action for CI (https://redirect.github.com/codehaus-plexus/plexus-classworlds/pull/101;>#101) https://github.com/slachiewicz;>@slachiewicz Cleanup gha - use same defaults from template (https://redirect.github.com/codehaus-plexus/plexus-classworlds/pull/87;>#87) https://github.com/slachiewicz;>@slachiewicz 2.7.0 What's Changed Bump actions/cache from v2.1.1 to v2.1.3 by https://github.com/dependabot;>@dependabot in https://redirect.github.com/codehaus-plexus/plexus-classworlds/pull/13;>codehaus-plexus/plexus-classworlds#13 Bump release-drafter/release-drafter from v5.11.0 to v5.15.0 by https://github.com/dependabot;>@dependabot in https://redirect.github.com/codehaus-plexus/plexus-classworlds/pull/18;>codehaus-plexus/plexus-classworlds#18 Bump actions/cache from v2.1.3 to v2.1.4 by https://github.com/dependabot;>@dependabot in https://redirect.github.com/codehaus-plexus/plexus-classworlds/pull/16;>codehaus-plexus/plexus-classworlds#16 Bump maven-enforcer-plugin from 1.3.1 to 1.4.1 by https://github.com/dependabot;>@dependabot in https://redirect.github.com/codehaus-plexus/plexus-classworlds/pull/8;>codehaus-plexus/plexus-classworlds#8 Bump actions/cache from v2.1.4 to v2.1.5 by https://github.com/dependabot;>@dependabot in https://redirect.github.com/codehaus-plexus/plexus-classworlds/pull/21;>codehaus-plexus/plexus-classworlds#21 Adding support for PPC64LE by https://github.com/ezeeyahoo;>@ezeeyahoo in https://redirect.github.com/codehaus-plexus/plexus-classworlds/pull/6;>codehaus-plexus/plexus-classworlds#6 Bump actions/cache from 2.1.5 to 2.1.6 by https://github.com/dependabot;>@dependabot in https://redirect.github.com/codehaus-plexus/plexus-classworlds/pull/26;>codehaus-plexus/plexus-classworlds#26 Bump actions/setup-java from 1 to 2.2.0 by https://github.com/dependabot;>@dependabot in https://redirect.github.com/codehaus-plexus/plexus-classworlds/pull/30;>codehaus-plexus/plexus-classworlds#30 Bump actions/setup-java from 2.2.0 to 2.3.0 by https://github.com/dependabot;>@dependabot in https://redirect.github.com/codehaus-plexus/plexus-classworlds/pull/31;>codehaus-plexus/plexus-classworlds#31 Bump actions/setup-java from 2.3.0 to 2.3.1 by https://github.com/dependabot;>@dependabot in https://redirect.github.com/codehaus-plexus/plexus-classworlds/pull/33;>codehaus-plexus/plexus-classworlds#33 Bump maven-dependency-plugin from 2.0 to 3.2.0 by https://github.com/dependabot;>@dependabot in https://redirect.github.com/codehaus-plexus/plexus-classworlds/pull/27;>codehaus-plexus/plexus-classworlds#27 Bump maven-javadoc-plugin from 2.9.1 to 3.3.1 by https://github.com/dependabot;>@dependabot in https://redirect.github.com/codehaus-plexus/plexus-classworlds/pull/32;>codehaus-plexus/plexus-classworlds#32 Bump actions/cache from 2.1.6 to 2.1.7 by https://github.com/dependabot;>@dependabot in https://redirect.github.com/codehaus-plexus/plexus-classworlds/pull/34;>codehaus-plexus/plexus-classworlds#34 Bump actions/setup-java from 2.3.1 to 2.4.0 by https://github.com/dependabot;>@dependabot in https://redirect.github.com/codehaus-plexus/plexus-classworlds/pull/35;>codehaus-plexus/plexus-classworlds#35 Bump actions/setup-java from 2.4.0 to 2.5.0 by https://github.com/dependabot;>@dependabot in https://redirect.github.com/codehaus-plexus/plexus-classworlds/pull/37;>codehaus-plexus/plexus-classworlds#37 Bump release-drafter/release-drafter from 5.15.0 to 5.18.0 by https://github.com/dependabot;>@dependabot in https://redirect.github.com/codehaus-plexus/plexus-classworlds/pull/42;>codehaus-plexus/plexus-classworlds#42 Bump release-drafter/release-drafter from 5.18.0 to 5.18.1 by https://github.com/dependabot;>@dependabot in https://redirect.github.com/codehaus-plexus/plexus-classworlds/pull/43;>codehaus-plexus/plexus-classworlds#43 Bump maven-enforcer-plugin from 1.4.1 to 3.0.0 by https://github.com/dependabot;>@dependabot in
[PR] Bump mockitoVersion from 5.7.0 to 5.12.0 [maven]
dependabot[bot] opened a new pull request, #1521: URL: https://github.com/apache/maven/pull/1521 Bumps `mockitoVersion` from 5.7.0 to 5.12.0. Updates `org.mockito:mockito-bom` from 5.7.0 to 5.12.0 Release notes Sourced from https://github.com/mockito/mockito/releases;>org.mockito:mockito-bom's releases. v5.12.0 Changelog generated by https://github.com/shipkit/shipkit-changelog;>Shipkit Changelog Gradle Plugin 5.12.0 2024-05-11 - https://github.com/mockito/mockito/compare/v5.11.0...v5.12.0;>25 commit(s) by Piotr Przybylak, Stefano Cordio, Tim van der Lippe, dependabot[bot], jonghoonpark Bump com.gradle.enterprise from 3.17.2 to 3.17.3 [(https://redirect.github.com/mockito/mockito/issues/3341;>#3341)](https://redirect.github.com/mockito/mockito/pull/3341;>mockito/mockito#3341) Bump org.jetbrains.kotlin:kotlin-stdlib from 1.9.23 to 1.9.24 [(https://redirect.github.com/mockito/mockito/issues/3339;>#3339)](https://redirect.github.com/mockito/mockito/pull/3339;>mockito/mockito#3339) Bump versions.bytebuddy from 1.14.14 to 1.14.15 [(https://redirect.github.com/mockito/mockito/issues/3338;>#3338)](https://redirect.github.com/mockito/mockito/pull/3338;>mockito/mockito#3338) Bump org.shipkit:shipkit-auto-version from 2.0.6 to 2.0.7 [(https://redirect.github.com/mockito/mockito/issues/3337;>#3337)](https://redirect.github.com/mockito/mockito/pull/3337;>mockito/mockito#3337) Bump org.jetbrains.kotlin:kotlin-gradle-plugin from 1.9.23 to 1.9.24 [(https://redirect.github.com/mockito/mockito/issues/3336;>#3336)](https://redirect.github.com/mockito/mockito/pull/3336;>mockito/mockito#3336) Fixes https://redirect.github.com/mockito/mockito/issues/3331;>#3331 : Fix AdditionalMatchers.and() and AdditionalMatchers.or() not to swap the order of matchers [(https://redirect.github.com/mockito/mockito/issues/3335;>#3335)](https://redirect.github.com/mockito/mockito/pull/3335;>mockito/mockito#3335) AdditionalMatchers.and() and or() swap matcher order [(https://redirect.github.com/mockito/mockito/issues/3331;>#3331)](https://redirect.github.com/mockito/mockito/issues/3331;>mockito/mockito#3331) Bump gradle/wrapper-validation-action from 3.3.1 to 3.3.2 [(https://redirect.github.com/mockito/mockito/issues/3327;>#3327)](https://redirect.github.com/mockito/mockito/pull/3327;>mockito/mockito#3327) Bump versions.bytebuddy from 1.14.13 to 1.14.14 [(https://redirect.github.com/mockito/mockito/issues/3324;>#3324)](https://redirect.github.com/mockito/mockito/pull/3324;>mockito/mockito#3324) Bump org.shipkit:shipkit-auto-version from 2.0.5 to 2.0.6 [(https://redirect.github.com/mockito/mockito/issues/3322;>#3322)](https://redirect.github.com/mockito/mockito/pull/3322;>mockito/mockito#3322) Bump gradle/wrapper-validation-action from 3.3.0 to 3.3.1 [(https://redirect.github.com/mockito/mockito/issues/3320;>#3320)](https://redirect.github.com/mockito/mockito/pull/3320;>mockito/mockito#3320) Bump com.gradle.enterprise from 3.17 to 3.17.2 [(https://redirect.github.com/mockito/mockito/issues/3318;>#3318)](https://redirect.github.com/mockito/mockito/pull/3318;>mockito/mockito#3318) Bump gradle/wrapper-validation-action from 2.1.2 to 3.3.0 [(https://redirect.github.com/mockito/mockito/issues/3317;>#3317)](https://redirect.github.com/mockito/mockito/pull/3317;>mockito/mockito#3317) Update codecov-action version [(https://redirect.github.com/mockito/mockito/issues/3316;>#3316)](https://redirect.github.com/mockito/mockito/pull/3316;>mockito/mockito#3316) Bump com.google.googlejavaformat:google-java-format from 1.21.0 to 1.22.0 [(https://redirect.github.com/mockito/mockito/issues/3312;>#3312)](https://redirect.github.com/mockito/mockito/pull/3312;>mockito/mockito#3312) Bump com.gradle.enterprise from 3.16.2 to 3.17 [(https://redirect.github.com/mockito/mockito/issues/3311;>#3311)](https://redirect.github.com/mockito/mockito/pull/3311;>mockito/mockito#3311) Bump versions.bytebuddy from 1.14.12 to 1.14.13 [(https://redirect.github.com/mockito/mockito/issues/3308;>#3308)](https://redirect.github.com/mockito/mockito/pull/3308;>mockito/mockito#3308) Fix README logo [(https://redirect.github.com/mockito/mockito/issues/3305;>#3305)](https://redirect.github.com/mockito/mockito/pull/3305;>mockito/mockito#3305) Bump gradle/wrapper-validation-action from 2.1.1 to 2.1.2 [(https://redirect.github.com/mockito/mockito/issues/3303;>#3303)](https://redirect.github.com/mockito/mockito/pull/3303;>mockito/mockito#3303) Bump org.shipkit:shipkit-auto-version from 2.0.4 to 2.0.5 [(https://redirect.github.com/mockito/mockito/issues/3298;>#3298)](https://redirect.github.com/mockito/mockito/pull/3298;>mockito/mockito#3298) Bump org.jetbrains.kotlin:kotlin-gradle-plugin from 1.9.22 to 1.9.23 [(https://redirect.github.com/mockito/mockito/issues/3296;>#3296)](https://redirect.github.com/mockito/mockito/pull/3296;>mockito/mockito#3296) Bump
[PR] Bump com.github.siom79.japicmp:japicmp-maven-plugin from 0.17.2 to 0.21.2 [maven]
dependabot[bot] opened a new pull request, #1520: URL: https://github.com/apache/maven/pull/1520 Bumps [com.github.siom79.japicmp:japicmp-maven-plugin](https://github.com/siom79/japicmp) from 0.17.2 to 0.21.2. Release notes Sourced from https://github.com/siom79/japicmp/releases;>com.github.siom79.japicmp:japicmp-maven-plugin's releases. 0.18.3 skip-Tag in plugin configuration and -Djapicmp.skip work https://redirect.github.com/siom79/japicmp/issues/366;>#366 Do not report any incompatibilities if class becomes public. https://redirect.github.com/siom79/japicmp/issues/365;>#365 Commits https://github.com/siom79/japicmp/commit/1d75ed7bf40136c50d810a3c3675e6bb7ad8ed8f;>1d75ed7 [maven-release-plugin] prepare release japicmp-base-0.21.2 https://github.com/siom79/japicmp/commit/317f2638c93bf639471b79e74e27965d8a148c6e;>317f263 Merge pull request https://redirect.github.com/siom79/japicmp/issues/397;>#397 from Billlynch/master https://github.com/siom79/japicmp/commit/7a235952659cb82687456bf6be225b4a9a8fa80a;>7a23595 remove formatting noise https://github.com/siom79/japicmp/commit/ac02dc88cc18dbf328e0fb5d7422d543b90687e5;>ac02dc8 refactor https://github.com/siom79/japicmp/commit/8a10b717347c0c7a96d1b5eb5b55a222d648d899;>8a10b71 fix: check changes in return types https://github.com/siom79/japicmp/commit/68727ed928502f0062cab4177eea6efe21c2e697;>68727ed [maven-release-plugin] prepare for next development iteration https://github.com/siom79/japicmp/commit/54d3d807348e5747d5d88c7717be298af0e7b8d8;>54d3d80 [maven-release-plugin] prepare release japicmp-base-0.21.1 https://github.com/siom79/japicmp/commit/14f539afbd018a8e69337eb990d7a3afca0170e4;>14f539a upgraded version in *.md files to 0.21.1 https://github.com/siom79/japicmp/commit/dd33ea5c1d644fcc5ee2d8133eee41eac1163375;>dd33ea5 ReleaseNotes.md https://github.com/siom79/japicmp/commit/66dddc6d94667bc28800219f111bf85b1e93a993;>66dddc6 Merge pull request https://redirect.github.com/siom79/japicmp/issues/396;>#396 from guillermocalvo/expand-test-coverage-for-annotati... Additional commits viewable in https://github.com/siom79/japicmp/compare/japicmp-base-0.17.2...japicmp-base-0.21.2;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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
[PR] Bump org.codehaus.mojo:build-helper-maven-plugin from 3.4.0 to 3.5.0 [maven]
dependabot[bot] opened a new pull request, #1516: URL: https://github.com/apache/maven/pull/1516 Bumps [org.codehaus.mojo:build-helper-maven-plugin](https://github.com/mojohaus/build-helper-maven-plugin) from 3.4.0 to 3.5.0. Release notes Sourced from https://github.com/mojohaus/build-helper-maven-plugin/releases;>org.codehaus.mojo:build-helper-maven-plugin's releases. 3.5.0 Changes New features and improvements Add skipIfMissing flag (https://redirect.github.com/mojohaus/build-helper-maven-plugin/pull/187;>#187) https://github.com/hgschmie;>@hgschmie Add skip flags (https://redirect.github.com/mojohaus/build-helper-maven-plugin/pull/186;>#186) https://github.com/hgschmie;>@hgschmie Deprecate maven-version goal (https://redirect.github.com/mojohaus/build-helper-maven-plugin/pull/191;>#191) https://github.com/slawekjaranowski;>@slawekjaranowski Dependency updates Bump org.codehaus.mojo:mojo-parent from 76 to 77 (https://redirect.github.com/mojohaus/build-helper-maven-plugin/pull/190;>#190) https://github.com/dependabot;>@dependabot Bump mojo-parent from 75 to 76 (https://redirect.github.com/mojohaus/build-helper-maven-plugin/pull/185;>#185) https://github.com/dependabot;>@dependabot Bump mojo-parent from 74 to 75 (https://redirect.github.com/mojohaus/build-helper-maven-plugin/pull/184;>#184) https://github.com/dependabot;>@dependabot Bump plexus-utils from 3.5.1 to 4.0.0 (https://redirect.github.com/mojohaus/build-helper-maven-plugin/pull/183;>#183) https://github.com/dependabot;>@dependabot Bump maven-plugin-annotations from 3.8.2 to 3.9.0 (https://redirect.github.com/mojohaus/build-helper-maven-plugin/pull/182;>#182) https://github.com/dependabot;>@dependabot Maintenance Use plugins versions from parent in ITs (https://redirect.github.com/mojohaus/build-helper-maven-plugin/pull/192;>#192) https://github.com/slawekjaranowski;>@slawekjaranowski Use Maven Apache shared GitHub action (https://redirect.github.com/mojohaus/build-helper-maven-plugin/pull/189;>#189) https://github.com/slawekjaranowski;>@slawekjaranowski Fix antrun version in ITs (https://redirect.github.com/mojohaus/build-helper-maven-plugin/pull/188;>#188) https://github.com/slawekjaranowski;>@slawekjaranowski Bump mojo-parent from 75 to 76 (https://redirect.github.com/mojohaus/build-helper-maven-plugin/pull/185;>#185) https://github.com/dependabot;>@dependabot Commits https://github.com/mojohaus/build-helper-maven-plugin/commit/820d0a8107a7dcad4fe0c9e9b0cf44e9ceefd807;>820d0a8 [maven-release-plugin] prepare release 3.5.0 https://github.com/mojohaus/build-helper-maven-plugin/commit/497a9f58a035e80bf401eb6fe01dbf3fc312a032;>497a9f5 Use plugins versions from parent in ITs https://github.com/mojohaus/build-helper-maven-plugin/commit/ad1076e467aa818c3f7e7596d0a51958f35e70d1;>ad1076e Add skipIfMissing flag (https://redirect.github.com/mojohaus/build-helper-maven-plugin/issues/187;>#187) https://github.com/mojohaus/build-helper-maven-plugin/commit/faab9369445fef414a671a9df41cafcbd2d3bf7e;>faab936 Bump project version to next minor 3.5.0 https://github.com/mojohaus/build-helper-maven-plugin/commit/b49b7e6c2cffe430fa39a6bb0bcc9d323e523eb8;>b49b7e6 Add skip flags (https://redirect.github.com/mojohaus/build-helper-maven-plugin/issues/186;>#186) https://github.com/mojohaus/build-helper-maven-plugin/commit/223744155deb6b01bd401a911cc5245bafee753b;>2237441 Deprecate maven-version goal https://github.com/mojohaus/build-helper-maven-plugin/commit/ef477d8b3d1bed075937a0cb68535330fcf77f29;>ef477d8 Drop stale action https://github.com/mojohaus/build-helper-maven-plugin/commit/3df0c7f86bf6015254906ebc306495dc2fedb766;>3df0c7f Bump org.codehaus.mojo:mojo-parent from 76 to 77 https://github.com/mojohaus/build-helper-maven-plugin/commit/e6e9ba6f1d9f365413fbd8eb506781ebaca6e1e6;>e6e9ba6 Use Maven Apache shared GitHub action https://github.com/mojohaus/build-helper-maven-plugin/commit/d7cb1c5f100fe22d51eb0607104b243d536908d0;>d7cb1c5 Fix antrun version in ITs Additional commits viewable in https://github.com/mojohaus/build-helper-maven-plugin/compare/3.4.0...3.5.0;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this
[PR] Bump ch.qos.logback:logback-classic from 1.2.13 to 1.5.6 [maven]
dependabot[bot] opened a new pull request, #1515: URL: https://github.com/apache/maven/pull/1515 Bumps [ch.qos.logback:logback-classic](https://github.com/qos-ch/logback) from 1.2.13 to 1.5.6. Commits https://github.com/qos-ch/logback/commit/7812a55f3280fbb74076b2512a06dd34230a83f1;>7812a55 prepare release 1.5.6 https://github.com/qos-ch/logback/commit/759fc25ee384354a9159e64aa1fb7269d770fce4;>759fc25 fix issues/805 i.e. LOGBACK-1768, included file with inner conditional https://github.com/qos-ch/logback/commit/3d5563899f3f9a2524d37333017007a291e37e79;>3d55638 start work on 1.5.6-SNAPSHOT https://github.com/qos-ch/logback/commit/a91d2b6a562ac67e6bc247c7c7d8ed48d8479867;>a91d2b6 notes about javadocs https://github.com/qos-ch/logback/commit/c7c5e89a857bba3fc09f1912cc912b25ee124505;>c7c5e89 prepare release 1.5.5 https://github.com/qos-ch/logback/commit/7db87970b7fae4741c36a04c4283ba8ca1d8b3cb;>7db8797 upgrade build to slf4j 2.0.13 https://github.com/qos-ch/logback/commit/f9c04d2b5562e44997a80e350b88960cbf3a0bb1;>f9c04d2 test inclusion with conditionals https://github.com/qos-ch/logback/commit/f32ed30166307385236b9f373103bd708e2f6857;>f32ed30 remove support for metaannotations for NoAutoStart annotation https://github.com/qos-ch/logback/commit/4476edd0f3415008506bdaa23ce855b3eae5086a;>4476edd Search for https://github.com/NoAutoStart;>@NoAutoStart annotations in ancestor hierarchy, implemented interf... https://github.com/qos-ch/logback/commit/a649c605be4c88a9f6020cc7eb1738abd01026a2;>a649c60 rename IncludeActionTest as IncludeModelHandlerTest Additional commits viewable in https://github.com/qos-ch/logback/compare/v_1.2.13...v_1.5.6;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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
[PR] Bump net.bytebuddy:byte-buddy from 1.14.9 to 1.14.15 [maven]
dependabot[bot] opened a new pull request, #1514: URL: https://github.com/apache/maven/pull/1514 Bumps [net.bytebuddy:byte-buddy](https://github.com/raphw/byte-buddy) from 1.14.9 to 1.14.15. Release notes Sourced from https://github.com/raphw/byte-buddy/releases;>net.bytebuddy:byte-buddy's releases. Byte Buddy 1.14.15 Allow attaching from root on J9. Byte Buddy 1.14.14 Adjust type validation to accept additional names that are legal in the class file format. Fix dynamic attach on Windows when a service user is active. Avoid failure when using Android's strict mode. Byte Buddy 1.14.13 Avoid resolving type variables when generic type processing is disabled. Improve error message for Byte Buddy agent external attach. Fix build for modular jars when using later version than Java 8. Byte Buddy 1.14.12 Pin proxy class file version to avoid implicit changes when using Graal native image. Add support for Java 23. Add missing @MaybeNull annotation. Byte Buddy 1.14.11 Adjusts Gradle plugin to support Gradle 8.4 without warnings. Avoid blurry exception on build plugin for fail fast. byte-buddy-1.14.10 Add lazy facade to default TypePool in AgentBuilder to avoid parsing of types ignored by name. Avoid module info classes in Android plugin. Changelog Sourced from https://github.com/raphw/byte-buddy/blob/master/release-notes.md;>net.bytebuddy:byte-buddy's changelog. Byte Buddy release notes 23. April 2024: version 1.14.14 Adjust type validation to accept additional names that are legal in the class file format. Fix dynamic attach on Windows when a service user is active. Avoid failure when using Android's strict mode. 28. March 2024: version 1.14.13 Avoid resolving type variables when generic type processing is disabled. Improve error message for Byte Buddy agent external attach. Fix build for modular jars when using later version than Java 8. 16. February 2024: version 1.14.12 Pin proxy class file version to avoid implicit changes when using Graal native image. Add support for Java 23. Add missing @MaybeNull annotation. 21. December 2023: version 1.14.11 Adjusts Gradle plugin to support Gradle 8.4 without warnings. Avoid blurry exception on build plugin for fail fast. 9. October 2023: version 1.14.10 Add lazy facade to default TypePool in AgentBuilder to avoid parsing of types ignored by name. Avoid module info classes in Android plugin. Commits https://github.com/raphw/byte-buddy/commit/a24599ab06e5d869383c9bf3ed600b25e055e3b2;>a24599a [maven-release-plugin] prepare release byte-buddy-1.14.15 https://github.com/raphw/byte-buddy/commit/0e0cbdf4dbfa60ec7972414a5be2bdd0e805021e;>0e0cbdf [release] Release new version https://github.com/raphw/byte-buddy/commit/5b5bcaf96013b27fc23b91fcb2bd57184d8d2d17;>5b5bcaf Minor code normalizations. https://github.com/raphw/byte-buddy/commit/189787960f8389e857c791a51af5e7f396e7e293;>1897879 Add missing forwarding. https://github.com/raphw/byte-buddy/commit/156ba853296fa6bcb688cdcaf249ec080d3746b0;>156ba85 J9 Allow attachment as root (https://redirect.github.com/raphw/byte-buddy/issues/1631;>#1631) https://github.com/raphw/byte-buddy/commit/01ed75b4b53bc43b54d8b7814c158cf310393c68;>01ed75b Switch from global property to explicit argument. https://github.com/raphw/byte-buddy/commit/f04d254b61e4f05fd647fbcbcb61de32fea1d652;>f04d254 Add property to allow disabling user check for J9 which does not seem to be i... https://github.com/raphw/byte-buddy/commit/5b7c966d82ac8e47d486111b1ce16c358c1b402b;>5b7c966 Update internal Byte Buddy. https://github.com/raphw/byte-buddy/commit/e258ec5be04f77060c1f99c6535ef30b6cad9a3b;>e258ec5 Update checkout plugin. https://github.com/raphw/byte-buddy/commit/61209f4785428aee60c3ea6d425355d59db3bf13;>61209f4 [maven-release-plugin] prepare for next development iteration Additional commits viewable in https://github.com/raphw/byte-buddy/compare/byte-buddy-1.14.9...byte-buddy-1.14.15;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR -
Re: [PR] Enable dependabot [maven]
gnodet merged PR #1513: URL: https://github.com/apache/maven/pull/1513 -- 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=17847269#comment-17847269
]
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_r1604933590
##
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:
`buildJob` is class generated by modello internally `MXSerializer` is used
Also here exception is generated by post-build scrip and message contains
output of it it also be 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
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_r1604933590
##
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:
`buildJob` is class generated by modello internally `MXSerializer` is used
Also here exception is generated by post-build scrip and message contains
output of it it also be 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] (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=17847268#comment-17847268
]
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_r1604929130
##
src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java:
##
@@ -1779,7 +1781,7 @@ private void writeJunitReport(BuildJob buildJob, String
safeFileName) throws Moj
if (buildLogFile != null && buildLogFile.exists()) {
getLog().debug("fileLogger:" + buildLogFile);
try {
-systemOut.setValue(FileUtils.fileRead(buildLogFile));
+
systemOut.setValue(StringEscapeUtils.escapeXml10(FileUtils.fileRead(buildLogFile)));
Review Comment:
`buildLogFile` contains raw output of tested Maven project so can contain
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
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_r1604929130
##
src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java:
##
@@ -1779,7 +1781,7 @@ private void writeJunitReport(BuildJob buildJob, String
safeFileName) throws Moj
if (buildLogFile != null && buildLogFile.exists()) {
getLog().debug("fileLogger:" + buildLogFile);
try {
-systemOut.setValue(FileUtils.fileRead(buildLogFile));
+
systemOut.setValue(StringEscapeUtils.escapeXml10(FileUtils.fileRead(buildLogFile)));
Review Comment:
`buildLogFile` contains raw output of tested Maven project so can contain
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
