[jira] [Updated] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0
[ https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MASSEMBLY-941: Description: Since MASSEMBLY-921 in 3.2.0, existing file permissions seem to be ignored when creating a tarball assembly, and files stored in the assembly do not have their original file permissions preserved. Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, existing file permissions are normally preserved. This is now broken in 3.2.0, unless the component descriptor explicitly sets the fileModes. This was discovered trying to prepare a release candidate for Apache Accumulo using the apache-23.pom parent POM's predefined `source-release-tar` descriptor using the `single` goal. We noticed that the resulting source-release tarball had stripped all the executable permissions from our scripts, instead of preserving them. This makes the resulting source release more difficult to build from source. A source-release assembly, and any other assembly that does not specify the file permissions explicitly, should preserve the existing file permissions, just as it used to with 3.1.1 and earlier. was: Since 3.2.0, existing file permissions seem to be ignored when creating a tarball assembly, and files stored in the assembly do not have their original file permissions preserved. Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, existing file permissions are normally preserved. This is now broken in 3.2.0, unless the component descriptor explicitly sets the fileModes. This was discovered trying to prepare a release candidate for Apache Accumulo using the apache-23.pom parent POM's predefined `source-release-tar` descriptor using the `single` goal. We noticed that the resulting source-release tarball had stripped all the executable permissions from our scripts, instead of preserving them. This makes the resulting source release more difficult to build from source. A source-release assembly, and any other assembly that does not specify the file permissions explicitly, should preserve the existing file permissions, just as it used to with 3.1.1 and earlier. > file permissions removed during assembly:single since 3.2.0 > --- > > Key: MASSEMBLY-941 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-941 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 3.2.0, 3.3.0 >Reporter: Christopher Tubbs >Assignee: Herve Boutemy >Priority: Critical > Fix For: next-release > > > Since MASSEMBLY-921 in 3.2.0, existing file permissions seem to be ignored > when creating a tarball assembly, and files stored in the assembly do not > have their original file permissions preserved. > Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, > existing file permissions are normally preserved. This is now broken in > 3.2.0, unless the component descriptor explicitly sets the fileModes. > This was discovered trying to prepare a release candidate for Apache Accumulo > using the apache-23.pom parent POM's predefined `source-release-tar` > descriptor using the `single` goal. We noticed that the resulting > source-release tarball had stripped all the executable permissions from our > scripts, instead of preserving them. This makes the resulting source release > more difficult to build from source. > A source-release assembly, and any other assembly that does not specify the > file permissions explicitly, should preserve the existing file permissions, > just as it used to with 3.1.1 and earlier. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-assembly-plugin] hboutemy commented on pull request #99: [SECURITY] Fix Temporary File Information Disclosure Vulnerability
hboutemy commented on PR #99: URL: https://github.com/apache/maven-assembly-plugin/pull/99#issuecomment-1403179912 notice that on security sensitive context on a shared server, a user is expected to set umask according to his security expectations but good idea: this update protects users against themselves :) -- 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
[GitHub] [maven-invoker-plugin] hgschmie commented on pull request #169: [MINVOKER-318] - invoker:install must resolve deps in 'test' scope
hgschmie commented on PR #169: URL: https://github.com/apache/maven-invoker-plugin/pull/169#issuecomment-1403132500 > We have discovered another bug here. > > When we have dependency which is part of reactor build, all attached artifacts from reactor project are copied, should be copied only listed as dependency. > > I think that this PR will change current behavior, which is correct in most of cases. > > We should resolve root cause not only one special case. Yes, you should. Except that the average bug on the MINVOKER JIRA is about three years open (there are bugs from 2014 open). You are failing your users. -- 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
[GitHub] [maven-invoker-plugin] hgschmie commented on pull request #169: [MINVOKER-318] - invoker:install must resolve deps in 'test' scope
hgschmie commented on PR #169: URL: https://github.com/apache/maven-invoker-plugin/pull/169#issuecomment-1403129672 > g...@github.com:jdbi/jdbi3-guava-cache Yes, it is g...@github.com:jdbi/jdbi-guava-cache Apologies. -- 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-7671) support higher JDK version specific options in jvm.config
[ https://issues.apache.org/jira/browse/MNG-7671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680424#comment-17680424 ] James Z.M. Gao commented on MNG-7671: - can we add the options to different file? like javaNN/ in the multi-release jar? > support higher JDK version specific options in jvm.config > - > > Key: MNG-7671 > URL: https://issues.apache.org/jira/browse/MNG-7671 > Project: Maven > Issue Type: New Feature >Reporter: James Z.M. Gao >Priority: Major > > When add some new options like --add-exports and --add-opens in jvm.config, > then the project cannot build on JDK 1.8 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-compiler-plugin] psiroky commented on a diff in pull request #170: [MCOMPILER-503] Resolve all annotation processor dependencies together
psiroky commented on code in PR #170: URL: https://github.com/apache/maven-compiler-plugin/pull/170#discussion_r1086070565 ## pom.xml: ## @@ -249,13 +249,8 @@ under the License. ! https://issues.apache.org/jira/browse/MINVOKER-174 --> - setup_jar_module/pom.xml - setup_jar_automodule/pom.xml - setup_x/pom.xml + setup*/pom.xml Review Comment: This makes sure that any new `setup` projects following the naming convention will be automatically picked up. If there is any potential concern with this approach, I can revert to the explicit list. -- 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
[GitHub] [maven-compiler-plugin] psiroky commented on a diff in pull request #170: [MCOMPILER-503] Resolve all annotation processor dependencies together
psiroky commented on code in PR #170: URL: https://github.com/apache/maven-compiler-plugin/pull/170#discussion_r1086068866 ## pom.xml: ## @@ -249,13 +249,8 @@ under the License. ! https://issues.apache.org/jira/browse/MINVOKER-174 --> - setup_jar_module/pom.xml - setup_jar_automodule/pom.xml - setup_x/pom.xml + setup*/pom.xml - - setup_x/** - Review Comment: Excludes are not supported by the invoker plugin, so this configuration was a noop -- 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] (MSITE-922) Using 4.0.0-M4 w/ maven-fluido-skin breaks table formatting in generated pages
[
https://issues.apache.org/jira/browse/MSITE-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680387#comment-17680387
]
Slawomir Jaranowski commented on MSITE-922:
---
For versions-m-p there is PR [https://github.com/mojohaus/versions/pull/905]
Please watch a version-m-p for next release.
> Using 4.0.0-M4 w/ maven-fluido-skin breaks table formatting in generated
> pages
> ---
>
> Key: MSITE-922
> URL: https://issues.apache.org/jira/browse/MSITE-922
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 4.0.0-M4
>Reporter: Dave Wichers
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> If, after you set the maven-site-plugin version to 4.0.0-M4 in the AntiSamy
> ([https://github.com/nahsra/antisamy]) pom.xml, you run: 'mvn site' against
> the main branch of this project:
> It generates the site docs just fine, but the tables are broken in many of
> the pages, which are rendered fine with the 4.0.0-M3 version of the
> maven-site-plugin.
> I did the following diff of 1 broken vs. OK generated site page file and
> here's what it shows:
> antisamy % diff target/site/spotbugs.html ../targetBroken/site/spotbugs.html
> 5c5
> {quote}< | Generated by Apache Maven Doxia Site Renderer 1.11.1 from
> com.github.spotbugs:spotbugs-maven-plugin:4.7.3.0:spotbugs at 2023-01-16
> ---
> > | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from
> >com.github.spotbugs:spotbugs-maven-plugin:4.7.3.0:spotbugs at 2023-01-16
> 8c8
> < http://www.w3.org/1999/xhtml; lang="en">
> ---
> > http://www.w3.org/1999/xhtml; lang="">
> 12c12
> <
> ---
> >
> 70c70
> < SpotBugs Bug Detector
> Report
> ---
> > SpotBugs Bug Detector Report
> 75,76c75
> < Summary
> <
> ---
> > Summary
> 87,88c86
> < Files
> <
> ---
> > Files
> 97,99c95,96
> < 1 name="org.owasp.validator.css.CssHandler">
> < name="org.owasp.validator.css.CssHandler">org.owasp.validator.css.CssHandler
> <
> ---
> > 1 > id="org.owasp.validator.css.CssHandler">
> > org.owasp.validator.css.CssHandler
> 123,125c120,121
> < Medium name="org.owasp.validator.css.CssScanner">
> < name="org.owasp.validator.css.CssScanner">org.owasp.validator.css.CssScanner
> <
> ---
> > Medium > id="org.owasp.validator.css.CssScanner">
> > org.owasp.validator.css.CssScanner
> {quote}
> Given that it works with 4.0.0-M3 this seems like a bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-compiler-plugin] psiroky commented on pull request #170: [MCOMPILER-503] Resolve all annotation processor dependencies together
psiroky commented on PR #170: URL: https://github.com/apache/maven-compiler-plugin/pull/170#issuecomment-1402826603 The plugin is used in the `annotation-user` project: https://github.com/apache/maven-compiler-plugin/pull/170/files#diff-82b7fbab158b18d75e40832a9a3edfee28aba32e67314a155f1bbc923f9b84e9R58. Just to make sure the annotation processor was actually executed and created those dummy files. I agree we should reuse the plugin, instead of copying it (it is now in three tests I think). Do you want me to do that in this PR, or in the next one? -- 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
[GitHub] [maven-compiler-plugin] slachiewicz commented on pull request #168: Bump mockito-core to 5.0.0 for Java11+
slachiewicz commented on PR #168: URL: https://github.com/apache/maven-compiler-plugin/pull/168#issuecomment-1402824833 We could report incompatibility, adjust our tests. But sooner or later we could switch to Java 11 -- 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
[GitHub] [maven-compiler-plugin] slawekjaranowski commented on pull request #168: Bump mockito-core to 5.0.0 for Java11+
slawekjaranowski commented on PR #168: URL: https://github.com/apache/maven-compiler-plugin/pull/168#issuecomment-1402822601 I'm not sure if it is safe. What will be when api between 4.x and 5.x sometime become incompatibility? -- 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
[GitHub] [maven-deploy-plugin] slawekjaranowski commented on pull request #34: [MDEPLOY-305] Improvement in DeployAtEnd
slawekjaranowski commented on PR #34: URL: https://github.com/apache/maven-deploy-plugin/pull/34#issuecomment-1402818002 @cstamas similar change like in m-install-p -- 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
[GitHub] [maven-deploy-plugin] slawekjaranowski opened a new pull request, #34: [MDEPLOY-305] Improvement in DeployAtEnd
slawekjaranowski opened a new pull request, #34: URL: https://github.com/apache/maven-deploy-plugin/pull/34 - Fix when module does not use m-deploy-p - Don't use metadata from main artifact to fetch pom.xml - Deploy all artifacts in one request --- Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MDEPLOY) 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. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MDEPLOY-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MDEPLOY-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. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] 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. - [x] 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) - [x] 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
[GitHub] [maven-compiler-plugin] slawekjaranowski commented on pull request #170: [MCOMPILER-503] Resolve all annotation processor dependencies together
slawekjaranowski commented on PR #170: URL: https://github.com/apache/maven-compiler-plugin/pull/170#issuecomment-1402800311 I don't see where plugin from annotation-verify is executed. We can put such plugin in separate setup-xxx test with install goal and next use plugin in your IT test. By the way ... configuration for invoker in project is to fix - I will take care about it. -- 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
[GitHub] [maven-compiler-plugin] cstamas commented on pull request #170: [MCOMPILER-503] Resolve all annotation processor dependencies together
cstamas commented on PR #170: URL: https://github.com/apache/maven-compiler-plugin/pull/170#issuecomment-1402785476 I do, but two pairs of eyes are better than m one -- 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] (MSITE-922) Using 4.0.0-M4 w/ maven-fluido-skin breaks table formatting in generated pages
[
https://issues.apache.org/jira/browse/MSITE-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680376#comment-17680376
]
Dave Wichers edited comment on MSITE-922 at 1/24/23 10:37 PM:
--
OK, so I tested the new maven-project-info-reports-plugin and the PMD plugin
with 4.0.0.M4 and fluido-skin 2.0.0.M2 and both are fixed, so that's good.
Still waiting on Spotbugs, and the versions-maven-plugin fixes. When those two
are fixed, I'll upgrade everything. If you can let me know when the the
versions-maven-plugin fix is released, I'd appreciate that. Thx.
was (Author: davewichers):
OK, so I tested the new maven-project-info-reports-plugin and the PMD plugin
with 4.0.0.M4 and fluido-skin 2.0.0.M2 and PMD and both are fixed,, so that's
good. Still waiting on Spotbugs, and the versions-maven-plugin fixes. When
those two are fixed, I'll upgrade everything. If you can let me know when the
the versions-maven-plugin fix is released, I'd appreciate that. Thx.
> Using 4.0.0-M4 w/ maven-fluido-skin breaks table formatting in generated
> pages
> ---
>
> Key: MSITE-922
> URL: https://issues.apache.org/jira/browse/MSITE-922
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 4.0.0-M4
>Reporter: Dave Wichers
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> If, after you set the maven-site-plugin version to 4.0.0-M4 in the AntiSamy
> ([https://github.com/nahsra/antisamy]) pom.xml, you run: 'mvn site' against
> the main branch of this project:
> It generates the site docs just fine, but the tables are broken in many of
> the pages, which are rendered fine with the 4.0.0-M3 version of the
> maven-site-plugin.
> I did the following diff of 1 broken vs. OK generated site page file and
> here's what it shows:
> antisamy % diff target/site/spotbugs.html ../targetBroken/site/spotbugs.html
> 5c5
> {quote}< | Generated by Apache Maven Doxia Site Renderer 1.11.1 from
> com.github.spotbugs:spotbugs-maven-plugin:4.7.3.0:spotbugs at 2023-01-16
> ---
> > | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from
> >com.github.spotbugs:spotbugs-maven-plugin:4.7.3.0:spotbugs at 2023-01-16
> 8c8
> < http://www.w3.org/1999/xhtml; lang="en">
> ---
> > http://www.w3.org/1999/xhtml; lang="">
> 12c12
> <
> ---
> >
> 70c70
> < SpotBugs Bug Detector
> Report
> ---
> > SpotBugs Bug Detector Report
> 75,76c75
> < Summary
> <
> ---
> > Summary
> 87,88c86
> < Files
> <
> ---
> > Files
> 97,99c95,96
> < 1 name="org.owasp.validator.css.CssHandler">
> < name="org.owasp.validator.css.CssHandler">org.owasp.validator.css.CssHandler
> <
> ---
> > 1 > id="org.owasp.validator.css.CssHandler">
> > org.owasp.validator.css.CssHandler
> 123,125c120,121
> < Medium name="org.owasp.validator.css.CssScanner">
> < name="org.owasp.validator.css.CssScanner">org.owasp.validator.css.CssScanner
> <
> ---
> > Medium > id="org.owasp.validator.css.CssScanner">
> > org.owasp.validator.css.CssScanner
> {quote}
> Given that it works with 4.0.0-M3 this seems like a bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSITE-922) Using 4.0.0-M4 w/ maven-fluido-skin breaks table formatting in generated pages
[
https://issues.apache.org/jira/browse/MSITE-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680376#comment-17680376
]
Dave Wichers commented on MSITE-922:
OK, so I tested the new maven-project-info-reports-plugin and the PMD plugin
with 4.0.0.M4 and fluido-skin 2.0.0.M2 and PMD and both are fixed,, so that's
good. Still waiting on Spotbugs, and the versions-maven-plugin fixes. When
those two are fixed, I'll upgrade everything. If you can let me know when the
the versions-maven-plugin fix is released, I'd appreciate that. Thx.
> Using 4.0.0-M4 w/ maven-fluido-skin breaks table formatting in generated
> pages
> ---
>
> Key: MSITE-922
> URL: https://issues.apache.org/jira/browse/MSITE-922
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 4.0.0-M4
>Reporter: Dave Wichers
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> If, after you set the maven-site-plugin version to 4.0.0-M4 in the AntiSamy
> ([https://github.com/nahsra/antisamy]) pom.xml, you run: 'mvn site' against
> the main branch of this project:
> It generates the site docs just fine, but the tables are broken in many of
> the pages, which are rendered fine with the 4.0.0-M3 version of the
> maven-site-plugin.
> I did the following diff of 1 broken vs. OK generated site page file and
> here's what it shows:
> antisamy % diff target/site/spotbugs.html ../targetBroken/site/spotbugs.html
> 5c5
> {quote}< | Generated by Apache Maven Doxia Site Renderer 1.11.1 from
> com.github.spotbugs:spotbugs-maven-plugin:4.7.3.0:spotbugs at 2023-01-16
> ---
> > | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from
> >com.github.spotbugs:spotbugs-maven-plugin:4.7.3.0:spotbugs at 2023-01-16
> 8c8
> < http://www.w3.org/1999/xhtml; lang="en">
> ---
> > http://www.w3.org/1999/xhtml; lang="">
> 12c12
> <
> ---
> >
> 70c70
> < SpotBugs Bug Detector
> Report
> ---
> > SpotBugs Bug Detector Report
> 75,76c75
> < Summary
> <
> ---
> > Summary
> 87,88c86
> < Files
> <
> ---
> > Files
> 97,99c95,96
> < 1 name="org.owasp.validator.css.CssHandler">
> < name="org.owasp.validator.css.CssHandler">org.owasp.validator.css.CssHandler
> <
> ---
> > 1 > id="org.owasp.validator.css.CssHandler">
> > org.owasp.validator.css.CssHandler
> 123,125c120,121
> < Medium name="org.owasp.validator.css.CssScanner">
> < name="org.owasp.validator.css.CssScanner">org.owasp.validator.css.CssScanner
> <
> ---
> > Medium > id="org.owasp.validator.css.CssScanner">
> > org.owasp.validator.css.CssScanner
> {quote}
> Given that it works with 4.0.0-M3 this seems like a bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-compiler-plugin] psiroky commented on pull request #170: [MCOMPILER-503] Resolve all annotation processor dependencies together
psiroky commented on PR #170: URL: https://github.com/apache/maven-compiler-plugin/pull/170#issuecomment-1402783013 > we need Slawek I see :laughing:. I thought you have the merge permission as well, sorry about the fuzz. -- 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
[GitHub] [maven-compiler-plugin] cstamas commented on pull request #170: [MCOMPILER-503] Resolve all annotation processor dependencies together
cstamas commented on PR #170: URL: https://github.com/apache/maven-compiler-plugin/pull/170#issuecomment-1402777571 we need Slawek @slachiewicz -- 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
[GitHub] [maven-compiler-plugin] psiroky commented on pull request #170: [MCOMPILER-503] Resolve all annotation processor dependencies together
psiroky commented on PR #170: URL: https://github.com/apache/maven-compiler-plugin/pull/170#issuecomment-1402769435 @cstamas many thanks for the review (and the details around dependency resolution)! I am wondering - what else do we need to get this one merged? -- 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] (MCOMPILER-496) The resolve process of annotationProcessorPaths is not aware of WorkspaceReader
[
https://issues.apache.org/jira/browse/MCOMPILER-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680375#comment-17680375
]
Petr Široký commented on MCOMPILER-496:
---
I believe this has been fixed as part of MCOMPILER-522.
When running the ITs (e.g. {{MCOMPILER-203-processorpath}}), I seeing am the
following output:
{code}
...
-processorpath
/maven-compiler-plugin/target/it/MCOMPILER-203-processorpath/annotation-processor/target/classes:/maven-compiler-plugin/target/local-repo/org/apache/commons/commons-lang3/3.4/commons-lang3-3.4.jar
...
{code}
which I think suggests that now the annotation-processor is "picked-up" from
the multi module build.
> The resolve process of annotationProcessorPaths is not aware of
> WorkspaceReader
> ---
>
> Key: MCOMPILER-496
> URL: https://issues.apache.org/jira/browse/MCOMPILER-496
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Reporter: Tamas Cservenak
>Priority: Major
>
> Hence, it cannot resolve annotation processor from current multi module
> build, and it requires annotation processor to be installed/downloaded.
> Move off from legacy API and use something like maven-artifact-transfer
> instead of maven-compat that delivers Maven2 behaviour.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MSITE-922) Using 4.0.0-M4 w/ maven-fluido-skin breaks table formatting in generated pages
[
https://issues.apache.org/jira/browse/MSITE-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680374#comment-17680374
]
Michael Osipov edited comment on MSITE-922 at 1/24/23 10:13 PM:
Because [~sjaranowski] noticed these issues and I started fixing them. Shortly
after you reported it as well. That is why it does not compute for you. See the
plugin's release notes. They address your problem.
was (Author: michael-o):
Because [~sjaranowski] noticed these issues and I started fixing them. Shortly
after you reported it as well. That is why it does not compute for you. See the
plugin's release notes. The address your problem.
> Using 4.0.0-M4 w/ maven-fluido-skin breaks table formatting in generated
> pages
> ---
>
> Key: MSITE-922
> URL: https://issues.apache.org/jira/browse/MSITE-922
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 4.0.0-M4
>Reporter: Dave Wichers
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> If, after you set the maven-site-plugin version to 4.0.0-M4 in the AntiSamy
> ([https://github.com/nahsra/antisamy]) pom.xml, you run: 'mvn site' against
> the main branch of this project:
> It generates the site docs just fine, but the tables are broken in many of
> the pages, which are rendered fine with the 4.0.0-M3 version of the
> maven-site-plugin.
> I did the following diff of 1 broken vs. OK generated site page file and
> here's what it shows:
> antisamy % diff target/site/spotbugs.html ../targetBroken/site/spotbugs.html
> 5c5
> {quote}< | Generated by Apache Maven Doxia Site Renderer 1.11.1 from
> com.github.spotbugs:spotbugs-maven-plugin:4.7.3.0:spotbugs at 2023-01-16
> ---
> > | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from
> >com.github.spotbugs:spotbugs-maven-plugin:4.7.3.0:spotbugs at 2023-01-16
> 8c8
> < http://www.w3.org/1999/xhtml; lang="en">
> ---
> > http://www.w3.org/1999/xhtml; lang="">
> 12c12
> <
> ---
> >
> 70c70
> < SpotBugs Bug Detector
> Report
> ---
> > SpotBugs Bug Detector Report
> 75,76c75
> < Summary
> <
> ---
> > Summary
> 87,88c86
> < Files
> <
> ---
> > Files
> 97,99c95,96
> < 1 name="org.owasp.validator.css.CssHandler">
> < name="org.owasp.validator.css.CssHandler">org.owasp.validator.css.CssHandler
> <
> ---
> > 1 > id="org.owasp.validator.css.CssHandler">
> > org.owasp.validator.css.CssHandler
> 123,125c120,121
> < Medium name="org.owasp.validator.css.CssScanner">
> < name="org.owasp.validator.css.CssScanner">org.owasp.validator.css.CssScanner
> <
> ---
> > Medium > id="org.owasp.validator.css.CssScanner">
> > org.owasp.validator.css.CssScanner
> {quote}
> Given that it works with 4.0.0-M3 this seems like a bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSITE-922) Using 4.0.0-M4 w/ maven-fluido-skin breaks table formatting in generated pages
[
https://issues.apache.org/jira/browse/MSITE-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680374#comment-17680374
]
Michael Osipov commented on MSITE-922:
--
Because [~sjaranowski] noticed these issues and I started fixing them. Shortly
after you reported it as well. That is why it does not compute for you. See the
plugin's release notes. The address your problem.
> Using 4.0.0-M4 w/ maven-fluido-skin breaks table formatting in generated
> pages
> ---
>
> Key: MSITE-922
> URL: https://issues.apache.org/jira/browse/MSITE-922
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 4.0.0-M4
>Reporter: Dave Wichers
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> If, after you set the maven-site-plugin version to 4.0.0-M4 in the AntiSamy
> ([https://github.com/nahsra/antisamy]) pom.xml, you run: 'mvn site' against
> the main branch of this project:
> It generates the site docs just fine, but the tables are broken in many of
> the pages, which are rendered fine with the 4.0.0-M3 version of the
> maven-site-plugin.
> I did the following diff of 1 broken vs. OK generated site page file and
> here's what it shows:
> antisamy % diff target/site/spotbugs.html ../targetBroken/site/spotbugs.html
> 5c5
> {quote}< | Generated by Apache Maven Doxia Site Renderer 1.11.1 from
> com.github.spotbugs:spotbugs-maven-plugin:4.7.3.0:spotbugs at 2023-01-16
> ---
> > | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from
> >com.github.spotbugs:spotbugs-maven-plugin:4.7.3.0:spotbugs at 2023-01-16
> 8c8
> < http://www.w3.org/1999/xhtml; lang="en">
> ---
> > http://www.w3.org/1999/xhtml; lang="">
> 12c12
> <
> ---
> >
> 70c70
> < SpotBugs Bug Detector
> Report
> ---
> > SpotBugs Bug Detector Report
> 75,76c75
> < Summary
> <
> ---
> > Summary
> 87,88c86
> < Files
> <
> ---
> > Files
> 97,99c95,96
> < 1 name="org.owasp.validator.css.CssHandler">
> < name="org.owasp.validator.css.CssHandler">org.owasp.validator.css.CssHandler
> <
> ---
> > 1 > id="org.owasp.validator.css.CssHandler">
> > org.owasp.validator.css.CssHandler
> 123,125c120,121
> < Medium name="org.owasp.validator.css.CssScanner">
> < name="org.owasp.validator.css.CssScanner">org.owasp.validator.css.CssScanner
> <
> ---
> > Medium > id="org.owasp.validator.css.CssScanner">
> > org.owasp.validator.css.CssScanner
> {quote}
> Given that it works with 4.0.0-M3 this seems like a bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSITE-922) Using 4.0.0-M4 w/ maven-fluido-skin breaks table formatting in generated pages
[
https://issues.apache.org/jira/browse/MSITE-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680372#comment-17680372
]
Dave Wichers commented on MSITE-922:
OK, but that simply announces:
* [[ANN] Maven PMD Plugin 3.20.0
released|https://www.mail-archive.com/announce@maven.apache.org/msg01172.html]
Michael Osipov
* [[ANN] Maven Project Info Reports Plugin 3.4.2
released|https://www.mail-archive.com/announce@maven.apache.org/msg01171.html]
Michael Osipov
Which were released BEFORE you made the changes you are talking about being
released, I believe. The above were released on Jan 11th, but I raised this
issue on Jan 16th.
> Using 4.0.0-M4 w/ maven-fluido-skin breaks table formatting in generated
> pages
> ---
>
> Key: MSITE-922
> URL: https://issues.apache.org/jira/browse/MSITE-922
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 4.0.0-M4
>Reporter: Dave Wichers
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> If, after you set the maven-site-plugin version to 4.0.0-M4 in the AntiSamy
> ([https://github.com/nahsra/antisamy]) pom.xml, you run: 'mvn site' against
> the main branch of this project:
> It generates the site docs just fine, but the tables are broken in many of
> the pages, which are rendered fine with the 4.0.0-M3 version of the
> maven-site-plugin.
> I did the following diff of 1 broken vs. OK generated site page file and
> here's what it shows:
> antisamy % diff target/site/spotbugs.html ../targetBroken/site/spotbugs.html
> 5c5
> {quote}< | Generated by Apache Maven Doxia Site Renderer 1.11.1 from
> com.github.spotbugs:spotbugs-maven-plugin:4.7.3.0:spotbugs at 2023-01-16
> ---
> > | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from
> >com.github.spotbugs:spotbugs-maven-plugin:4.7.3.0:spotbugs at 2023-01-16
> 8c8
> < http://www.w3.org/1999/xhtml; lang="en">
> ---
> > http://www.w3.org/1999/xhtml; lang="">
> 12c12
> <
> ---
> >
> 70c70
> < SpotBugs Bug Detector
> Report
> ---
> > SpotBugs Bug Detector Report
> 75,76c75
> < Summary
> <
> ---
> > Summary
> 87,88c86
> < Files
> <
> ---
> > Files
> 97,99c95,96
> < 1 name="org.owasp.validator.css.CssHandler">
> < name="org.owasp.validator.css.CssHandler">org.owasp.validator.css.CssHandler
> <
> ---
> > 1 > id="org.owasp.validator.css.CssHandler">
> > org.owasp.validator.css.CssHandler
> 123,125c120,121
> < Medium name="org.owasp.validator.css.CssScanner">
> < name="org.owasp.validator.css.CssScanner">org.owasp.validator.css.CssScanner
> <
> ---
> > Medium > id="org.owasp.validator.css.CssScanner">
> > org.owasp.validator.css.CssScanner
> {quote}
> Given that it works with 4.0.0-M3 this seems like a bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSITE-922) Using 4.0.0-M4 w/ maven-fluido-skin breaks table formatting in generated pages
[
https://issues.apache.org/jira/browse/MSITE-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680367#comment-17680367
]
Michael Osipov commented on MSITE-922:
--
Here they are: https://www.mail-archive.com/announce@maven.apache.org/
All fixed and will address the table problem.
> Using 4.0.0-M4 w/ maven-fluido-skin breaks table formatting in generated
> pages
> ---
>
> Key: MSITE-922
> URL: https://issues.apache.org/jira/browse/MSITE-922
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 4.0.0-M4
>Reporter: Dave Wichers
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> If, after you set the maven-site-plugin version to 4.0.0-M4 in the AntiSamy
> ([https://github.com/nahsra/antisamy]) pom.xml, you run: 'mvn site' against
> the main branch of this project:
> It generates the site docs just fine, but the tables are broken in many of
> the pages, which are rendered fine with the 4.0.0-M3 version of the
> maven-site-plugin.
> I did the following diff of 1 broken vs. OK generated site page file and
> here's what it shows:
> antisamy % diff target/site/spotbugs.html ../targetBroken/site/spotbugs.html
> 5c5
> {quote}< | Generated by Apache Maven Doxia Site Renderer 1.11.1 from
> com.github.spotbugs:spotbugs-maven-plugin:4.7.3.0:spotbugs at 2023-01-16
> ---
> > | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from
> >com.github.spotbugs:spotbugs-maven-plugin:4.7.3.0:spotbugs at 2023-01-16
> 8c8
> < http://www.w3.org/1999/xhtml; lang="en">
> ---
> > http://www.w3.org/1999/xhtml; lang="">
> 12c12
> <
> ---
> >
> 70c70
> < SpotBugs Bug Detector
> Report
> ---
> > SpotBugs Bug Detector Report
> 75,76c75
> < Summary
> <
> ---
> > Summary
> 87,88c86
> < Files
> <
> ---
> > Files
> 97,99c95,96
> < 1 name="org.owasp.validator.css.CssHandler">
> < name="org.owasp.validator.css.CssHandler">org.owasp.validator.css.CssHandler
> <
> ---
> > 1 > id="org.owasp.validator.css.CssHandler">
> > org.owasp.validator.css.CssHandler
> 123,125c120,121
> < Medium name="org.owasp.validator.css.CssScanner">
> < name="org.owasp.validator.css.CssScanner">org.owasp.validator.css.CssScanner
> <
> ---
> > Medium > id="org.owasp.validator.css.CssScanner">
> > org.owasp.validator.css.CssScanner
> {quote}
> Given that it works with 4.0.0-M3 this seems like a bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-6437) Generic .uri suffix to get the URI representation of any file property
[
https://issues.apache.org/jira/browse/MNG-6437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680366#comment-17680366
]
Michael Osipov commented on MNG-6437:
-
I haven't reviewed either. Will try to do by end of month.
> Generic .uri suffix to get the URI representation of any file property
> --
>
> Key: MNG-6437
> URL: https://issues.apache.org/jira/browse/MNG-6437
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Affects Versions: 3.5.4
>Reporter: Claude Brisson
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-4, 4.0.0
>
>
> It's impossible to properly generate, for instance, a java policy file which
> needs files URIs, using either Cargo properties and filtered config files, or
> just filtered resources.
> In both cases, the problem is the impossibility to generate proper URIs when
> expanding Maven properties (see also MNG-3760).
> The candidate feature is to add a way to explicitly request the URI when
> expanding a property by means of a {{.uri}} suffix. The underlying
> {{getUri()}} method should rely on the correct {{Path#toUri()}} and neither
> {{File#toUri()}} nor {{File#toString()}}, see the SO reference in MNG-6386.
> For instance:
> * {{${project.basedir.uri}}} instead of the broken {{${project.baseUri}}}
> (and of course fix MNG-6436 otherwise it's useless)
> * {{${project.build.directory.uri}}}
> * {{${settings.localRepository.uri}}}
> * etc
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7671) support higher JDK version specific options in jvm.config
[ https://issues.apache.org/jira/browse/MNG-7671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680364#comment-17680364 ] Michael Osipov commented on MNG-7671: - This file is a very simple line by line expansion. I highly doubt that anyone would add logic to it. > support higher JDK version specific options in jvm.config > - > > Key: MNG-7671 > URL: https://issues.apache.org/jira/browse/MNG-7671 > Project: Maven > Issue Type: New Feature >Reporter: James Z.M. Gao >Priority: Major > > When add some new options like --add-exports and --add-opens in jvm.config, > then the project cannot build on JDK 1.8 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6437) Generic .uri suffix to get the URI representation of any file property
[
https://issues.apache.org/jira/browse/MNG-6437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680359#comment-17680359
]
Claude Brisson commented on MNG-6437:
-
I don't have the time to thoroughly check the PR, but the issue I raised seems
adressed.
> Generic .uri suffix to get the URI representation of any file property
> --
>
> Key: MNG-6437
> URL: https://issues.apache.org/jira/browse/MNG-6437
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Affects Versions: 3.5.4
>Reporter: Claude Brisson
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-4, 4.0.0
>
>
> It's impossible to properly generate, for instance, a java policy file which
> needs files URIs, using either Cargo properties and filtered config files, or
> just filtered resources.
> In both cases, the problem is the impossibility to generate proper URIs when
> expanding Maven properties (see also MNG-3760).
> The candidate feature is to add a way to explicitly request the URI when
> expanding a property by means of a {{.uri}} suffix. The underlying
> {{getUri()}} method should rely on the correct {{Path#toUri()}} and neither
> {{File#toUri()}} nor {{File#toString()}}, see the SO reference in MNG-6386.
> For instance:
> * {{${project.basedir.uri}}} instead of the broken {{${project.baseUri}}}
> (and of course fix MNG-6436 otherwise it's useless)
> * {{${project.build.directory.uri}}}
> * {{${settings.localRepository.uri}}}
> * etc
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (DOXIA-691) APT: Emit multiple authors in separate meta tags
Konrad Windszus created DOXIA-691:
-
Summary: APT: Emit multiple authors in separate meta tags
Key: DOXIA-691
URL: https://issues.apache.org/jira/browse/DOXIA-691
Project: Maven Doxia
Issue Type: Bug
Components: Module - Apt
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Currently multiple authors in the head section of an APT file (separated by
newline) are just emitted like this in XHTML (e.g. in
https://maven.apache.org/guides/mini/guide-configuring-plugins.html based on
https://github.com/apache/maven-site/blob/master/content/apt/guides/mini/guide-configuring-plugins.apt)
{code}
{code}
Instead multiple authors should end up in multiple dedicated meta tags (with
the same name "author") as the newline is not really a supported separator.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-690) Markdown Parser: Multiline metadata incorrectly rendered
[
https://issues.apache.org/jira/browse/DOXIA-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680319#comment-17680319
]
ASF GitHub Bot commented on DOXIA-690:
--
kwin opened a new pull request, #141:
URL: https://github.com/apache/maven-doxia/pull/141
MultiMarkdown)
Properly support multiline values in sink and parser. Always emit with
normalized separators.
> Markdown Parser: Multiline metadata incorrectly rendered
>
>
> Key: DOXIA-690
> URL: https://issues.apache.org/jira/browse/DOXIA-690
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Markdown uses the following metadata format in its sink:
> [http://fletcher.github.io/MultiMarkdown-5/metadata.html].
> In case a metadata key has multiple values on multiple lines it is emitted as
> following from the {{MarkdownSink}}:
> {code:java}
> title: Guide to creating a site
> author: Brett Porter
> Jason van Zyl
> date: 2015-07-18 {code}
> That leads to incorrect XHTML output as the second line for {{author}} is not
> detected correctly and instead of being emitted as metadata is emitted as
> regular paragraph in the HTML body. This is due to
> https://github.com/apache/maven-doxia/blob/7509feb03af4d4fb7d48b4f9ef38ff5c1a17a149/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownParser.java#L110
> only detecting single line metadata values.
> Although this might be a glitch of the underlying Markdown Parser
> implementation the metadata format explicitly recommends:
> {quote}
> To keep multiline metadata values from being confused with additional
> metadata, I recommend indenting each new line of metadata. If your metadata
> value includes a colon, it must be indented to keep it from being treated as
> a new key-value pair
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7671) support higher JDK version specific options in jvm.config
James Z.M. Gao created MNG-7671: --- Summary: support higher JDK version specific options in jvm.config Key: MNG-7671 URL: https://issues.apache.org/jira/browse/MNG-7671 Project: Maven Issue Type: New Feature Reporter: James Z.M. Gao When add some new options like --add-exports and --add-opens in jvm.config, then the project cannot build on JDK 1.8 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSITE-922) Using 4.0.0-M4 w/ maven-fluido-skin breaks table formatting in generated pages
[
https://issues.apache.org/jira/browse/MSITE-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680290#comment-17680290
]
Dave Wichers commented on MSITE-922:
[~michael-o] - You mentioned: "I have recently released MPIR and MPMD, those
should be fixed. Please test and report. A for versions-maven-plugin, I have
write permission to all Codehaus repos, I will take take of this valueable
plugin. For spotbugs, let's ask [~hazendaz]!" For MPMD I'm still seeing: 3.20.0
([https://central.sonatype.dev/artifact/org.apache.maven.plugins/maven-pmd-plugin/3.20.0])
and MPIR is still 3.4.2. I don't know what you mean by 'recently released', as
I don't know where/how to get the 'new' versions to test.
> Using 4.0.0-M4 w/ maven-fluido-skin breaks table formatting in generated
> pages
> ---
>
> Key: MSITE-922
> URL: https://issues.apache.org/jira/browse/MSITE-922
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 4.0.0-M4
>Reporter: Dave Wichers
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> If, after you set the maven-site-plugin version to 4.0.0-M4 in the AntiSamy
> ([https://github.com/nahsra/antisamy]) pom.xml, you run: 'mvn site' against
> the main branch of this project:
> It generates the site docs just fine, but the tables are broken in many of
> the pages, which are rendered fine with the 4.0.0-M3 version of the
> maven-site-plugin.
> I did the following diff of 1 broken vs. OK generated site page file and
> here's what it shows:
> antisamy % diff target/site/spotbugs.html ../targetBroken/site/spotbugs.html
> 5c5
> {quote}< | Generated by Apache Maven Doxia Site Renderer 1.11.1 from
> com.github.spotbugs:spotbugs-maven-plugin:4.7.3.0:spotbugs at 2023-01-16
> ---
> > | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from
> >com.github.spotbugs:spotbugs-maven-plugin:4.7.3.0:spotbugs at 2023-01-16
> 8c8
> < http://www.w3.org/1999/xhtml; lang="en">
> ---
> > http://www.w3.org/1999/xhtml; lang="">
> 12c12
> <
> ---
> >
> 70c70
> < SpotBugs Bug Detector
> Report
> ---
> > SpotBugs Bug Detector Report
> 75,76c75
> < Summary
> <
> ---
> > Summary
> 87,88c86
> < Files
> <
> ---
> > Files
> 97,99c95,96
> < 1 name="org.owasp.validator.css.CssHandler">
> < name="org.owasp.validator.css.CssHandler">org.owasp.validator.css.CssHandler
> <
> ---
> > 1 > id="org.owasp.validator.css.CssHandler">
> > org.owasp.validator.css.CssHandler
> 123,125c120,121
> < Medium name="org.owasp.validator.css.CssScanner">
> < name="org.owasp.validator.css.CssScanner">org.owasp.validator.css.CssScanner
> <
> ---
> > Medium > id="org.owasp.validator.css.CssScanner">
> > org.owasp.validator.css.CssScanner
> {quote}
> Given that it works with 4.0.0-M3 this seems like a bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-release] JLLeitschuh commented on pull request #160: [SECURITY] Fix Temporary File Information Disclosure Vulnerability
JLLeitschuh commented on PR #160: URL: https://github.com/apache/maven-release/pull/160#issuecomment-1402116132 Thanks @hboutemy, I've updated the PR descriptions here: https://github.com/JLLeitschuh/security-research/commit/3b47a72d1f838fc822db17b16db5e68d513ccb52 -- 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
[GitHub] [maven-release] JLLeitschuh commented on pull request #160: [SECURITY] Fix Temporary File Information Disclosure Vulnerability
JLLeitschuh commented on PR #160: URL: https://github.com/apache/maven-release/pull/160#issuecomment-1402080252 > If someone is sensitive on information visibility in a shared env, shouldn't he define umask accordingly? Probably, yes. TBH, I'm not a unix person, so you'll have to forgive my lack of knowledge on the proper terminology. I'll update the messaging. Thanks! -- 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
[GitHub] [maven-jar-plugin] jorsol commented on a diff in pull request #57: [MJAR-292] - Detect MRJAR and add Multi-Release manifest entry
jorsol commented on code in PR #57: URL: https://github.com/apache/maven-jar-plugin/pull/57#discussion_r1085312613 ## src/it/MJAR-292-detect-mjar/pom.xml: ## @@ -0,0 +1,101 @@ + + +http://maven.apache.org/POM/4.0.0; + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; + xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd;> + 4.0.0 + + org.apache.maven.plugins + mjar-292-detect-multi-release-jar + mjar-292-detect-multi-release-jar + Verifies that the multi-release jar contains the manifest entry + jar + 1.0-SNAPSHOT + + +UTF-8 + 2022-12-22T13:25:58Z + + + + + +org.apache.maven.plugins +maven-jar-plugin +@project.version@ + + + + myproject.HelloWorld + true + + + + false Review Comment: Included an example where the user has already defined the Multi-Release entry, even if it's false/true or any other value, it will be overridden to `Multi-Release: true` BTW, I tried to include many ITs validating different scenarios. -- 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
[GitHub] [maven-jar-plugin] jorsol commented on a diff in pull request #57: [MJAR-292] - Detect MRJAR and add Multi-Release manifest entry
jorsol commented on code in PR #57: URL: https://github.com/apache/maven-jar-plugin/pull/57#discussion_r1085312613 ## src/it/MJAR-292-detect-mjar/pom.xml: ## @@ -0,0 +1,101 @@ + + +http://maven.apache.org/POM/4.0.0; + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; + xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd;> + 4.0.0 + + org.apache.maven.plugins + mjar-292-detect-multi-release-jar + mjar-292-detect-multi-release-jar + Verifies that the multi-release jar contains the manifest entry + jar + 1.0-SNAPSHOT + + +UTF-8 + 2022-12-22T13:25:58Z + + + + + +org.apache.maven.plugins +maven-jar-plugin +@project.version@ + + + + myproject.HelloWorld + true + + + + false Review Comment: Included an example where the user has already defined the Multi-Release entry, even if it's false/true or any other value, it will be overridden to `Multi-Release: true` -- 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
[GitHub] [maven-mvnd] gnodet closed issue #637: Timeout waiting to connect to the Maven daemon
gnodet closed issue #637: Timeout waiting to connect to the Maven daemon URL: https://github.com/apache/maven-mvnd/issues/637 -- 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
[GitHub] [maven-mvnd] gnodet commented on issue #637: Timeout waiting to connect to the Maven daemon
gnodet commented on issue #637: URL: https://github.com/apache/maven-mvnd/issues/637#issuecomment-1401938360 This should be fixed by https://github.com/apache/maven-mvnd/pull/778, please reopen if needed. -- 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
[GitHub] [maven-mvnd] gnodet closed issue #710: Too many open files on Mac OS with JDK 11 and mvnd 0.8.2
gnodet closed issue #710: Too many open files on Mac OS with JDK 11 and mvnd 0.8.2 URL: https://github.com/apache/maven-mvnd/issues/710 -- 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
[GitHub] [maven-jar-plugin] jorsol commented on a diff in pull request #57: [MJAR-292] - Detect MRJAR and add Multi-Release manifest entry
jorsol commented on code in PR #57: URL: https://github.com/apache/maven-jar-plugin/pull/57#discussion_r1085305400 ## src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java: ## @@ -225,23 +237,24 @@ public File createArchive() jarContentFileSet.setIncludes( Arrays.asList( getIncludes() ) ); jarContentFileSet.setExcludes( Arrays.asList( getExcludes() ) ); -boolean containsModuleDescriptor = false; String[] includedFiles = fileSetManager.getIncludedFiles( jarContentFileSet ); -for ( String includedFile : includedFiles ) + +// May give false positives if the files is named as module descriptor +// but is not in the root of the archive or in the versioned area +// (and hence not actually a module descriptor). +// That is fine since the modular Jar archiver will gracefully +// handle such case. +// And also such case is unlikely to happen as file ending +// with "module-info.class" is unlikely to be included in Jar file +// unless it is a module descriptor. +boolean containsModuleDescriptor = +Arrays.stream( includedFiles ).anyMatch( p -> p.endsWith( MODULE_DESCRIPTOR_FILE_NAME ) ); Review Comment: 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
[GitHub] [maven-mvnd] gnodet commented on issue #705: Package crashes due to java.io.IOException
gnodet commented on issue #705: URL: https://github.com/apache/maven-mvnd/issues/705#issuecomment-1401932275 This is unexpected. The purge process should only remove files that have a last modified time earlier than the current date minus the purge period (which defaults to 7 days). So this should not affect daemons that are still alive. The exception however seems to indicate that the log file of a live daemon has been deleted... -- 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
[GitHub] [maven-jar-plugin] jorsol commented on a diff in pull request #57: [MJAR-292] - Detect MRJAR and add Multi-Release manifest entry
jorsol commented on code in PR #57:
URL: https://github.com/apache/maven-jar-plugin/pull/57#discussion_r1085296601
##
src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java:
##
@@ -225,23 +237,24 @@ public File createArchive()
jarContentFileSet.setIncludes( Arrays.asList( getIncludes() ) );
jarContentFileSet.setExcludes( Arrays.asList( getExcludes() ) );
-boolean containsModuleDescriptor = false;
String[] includedFiles = fileSetManager.getIncludedFiles(
jarContentFileSet );
-for ( String includedFile : includedFiles )
+
+// May give false positives if the files is named as module descriptor
+// but is not in the root of the archive or in the versioned area
+// (and hence not actually a module descriptor).
+// That is fine since the modular Jar archiver will gracefully
+// handle such case.
+// And also such case is unlikely to happen as file ending
+// with "module-info.class" is unlikely to be included in Jar file
+// unless it is a module descriptor.
+boolean containsModuleDescriptor =
+Arrays.stream( includedFiles ).anyMatch( p -> p.endsWith(
MODULE_DESCRIPTOR_FILE_NAME ) );
+
+if ( detectMultiReleaseJar && Arrays.stream( includedFiles ).anyMatch(
p -> p.startsWith( "META-INF" + SEPARATOR
++ "versions" + SEPARATOR ) ) )
{
-// May give false positives if the files is named as module
descriptor
-// but is not in the root of the archive or in the versioned area
-// (and hence not actually a module descriptor).
-// That is fine since the modular Jar archiver will gracefully
-// handle such case.
-// And also such case is unlikely to happen as file ending
-// with "module-info.class" is unlikely to be included in Jar file
-// unless it is a module descriptor.
-if ( includedFile.endsWith( MODULE_DESCRIPTOR_FILE_NAME ) )
-{
-containsModuleDescriptor = true;
-break;
-}
+getLog().debug( "Adding 'Multi-Release: true' manifest entry." );
+archive.addManifestEntry( "Multi-Release", "true" );
Review Comment:
In summary, no, we don't need to discover such case, if we detect the
versioned area, we set the Manifest Entry.
If the user already defined such configuration (as probably 99.9% of users
might have right now) then it will be overridden by this setting, the
`` section will become redundant since the _Maven Archiver_
handles this scenario using a `LinkedHashMap` and put the key and value on the
Map.
For those weird use-cases where the user don't want this behavior, the
property `maven.jar.detectMultiReleaseJar` could be disabled.
--
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
[GitHub] [maven-mvnd] orpiske commented on issue #770: Threads parameter is not working on Apple Silicon
orpiske commented on issue #770:
URL: https://github.com/apache/maven-mvnd/issues/770#issuecomment-1401921333
@gnodet thanks. This is what I have:
```
MAVEN_OPTS=-Xms2048m -Xmx3584m
MAVEN_HOME=/Users/opiske/.sdkman/candidates/maven/current
```
My `mvnd.properties` from MVND_HOME seems to use the default values:
```
cat $MVND_HOME/conf/mvnd.properties | grep -i thread
# MVND_MIN_THREADS
# The minimum number of threads to use when constructing the default {@code
-T} parameter for the daemon.
# This value is ignored if @{@code -T}, @{@code --threads} or {@code
-Dmvnd.threads} is specified on the command
# line, or if {@code mvnd.threads} is specified in {@code
~/.m2/mvnd.properties}.
# mvnd.minThreads = 1
# MVND_THREADS
# The number of threads to pass to the daemon; same syntax as Maven's {@code
-T}/{@code --threads} option. Ignored
# if the user passes @{@code -T}, @{@code --threads} or {@code
-Dmvnd.threads} on the command
# mvnd.threads =
# MVND_THREAD_STACK_SIZE
# JVM options for the daemon to specify the thread stack size
# mvnd.threadStackSize = 1M
```
And looking at one of my projects, this is what I have:
```
ls ~/code/java/camel/.mvn
extensions.xml jvm.config wrapper/
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Created] (MRESOLVER-315) Implement Preemptive Authentication feature for native transport
Slawomir Jaranowski created MRESOLVER-315:
-
Summary: Implement Preemptive Authentication feature for native
transport
Key: MRESOLVER-315
URL: https://issues.apache.org/jira/browse/MRESOLVER-315
Project: Maven Resolver
Issue Type: New Feature
Reporter: Slawomir Jaranowski
We can set {{Preemptive Authentication}} for wagon transports, like:
https://maven.apache.org/guides/mini/guide-http-settings.html#Example:_Using_Preemptive_Authentication
Such feature will be also valuable for native transport.
When I use repository manager which require authorization for all request also
for all GET, we have first request as anonymous and second as authorized user.
With it we can avoid not needed anonymous request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-mvnd] gnodet closed issue #669: runtime jdk requirement of java client (via mvnd.sh) should be aligned to JDK8
gnodet closed issue #669: runtime jdk requirement of java client (via mvnd.sh) should be aligned to JDK8 URL: https://github.com/apache/maven-mvnd/issues/669 -- 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
[GitHub] [maven-mvnd] gnodet commented on issue #669: runtime jdk requirement of java client (via mvnd.sh) should be aligned to JDK8
gnodet commented on issue #669: URL: https://github.com/apache/maven-mvnd/issues/669#issuecomment-1401912151 I think this issue can now be closed with the merge of #717 and #722. -- 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
[GitHub] [maven-mvnd] gnodet closed issue #708: exec-maven-plugin (exec:exec) output unexpected prefix for each line of stdout/stderr
gnodet closed issue #708: exec-maven-plugin (exec:exec) output unexpected prefix for each line of stdout/stderr URL: https://github.com/apache/maven-mvnd/issues/708 -- 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
[GitHub] [maven-mvnd] gnodet commented on issue #708: exec-maven-plugin (exec:exec) output unexpected prefix for each line of stdout/stderr
gnodet commented on issue #708: URL: https://github.com/apache/maven-mvnd/issues/708#issuecomment-1401908569 This is also fixed by https://github.com/apache/maven-mvnd/commit/b2bd0aaae5ff8627d6425ede8c1de16e77b5f194 -- 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
[GitHub] [maven-jar-plugin] jorsol commented on a diff in pull request #57: [MJAR-292] - Detect MRJAR and add Multi-Release manifest entry
jorsol commented on code in PR #57: URL: https://github.com/apache/maven-jar-plugin/pull/57#discussion_r1085261986 ## src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java: ## @@ -225,23 +237,24 @@ public File createArchive() jarContentFileSet.setIncludes( Arrays.asList( getIncludes() ) ); jarContentFileSet.setExcludes( Arrays.asList( getExcludes() ) ); -boolean containsModuleDescriptor = false; String[] includedFiles = fileSetManager.getIncludedFiles( jarContentFileSet ); -for ( String includedFile : includedFiles ) + +// May give false positives if the files is named as module descriptor +// but is not in the root of the archive or in the versioned area +// (and hence not actually a module descriptor). +// That is fine since the modular Jar archiver will gracefully +// handle such case. +// And also such case is unlikely to happen as file ending +// with "module-info.class" is unlikely to be included in Jar file +// unless it is a module descriptor. +boolean containsModuleDescriptor = +Arrays.stream( includedFiles ).anyMatch( p -> p.endsWith( MODULE_DESCRIPTOR_FILE_NAME ) ); Review Comment: Sure, will do. -- 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
[GitHub] [maven-jar-plugin] jorsol commented on a diff in pull request #57: [MJAR-292] - Detect MRJAR and add Multi-Release manifest entry
jorsol commented on code in PR #57:
URL: https://github.com/apache/maven-jar-plugin/pull/57#discussion_r1085261280
##
src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java:
##
@@ -225,23 +237,24 @@ public File createArchive()
jarContentFileSet.setIncludes( Arrays.asList( getIncludes() ) );
jarContentFileSet.setExcludes( Arrays.asList( getExcludes() ) );
-boolean containsModuleDescriptor = false;
String[] includedFiles = fileSetManager.getIncludedFiles(
jarContentFileSet );
-for ( String includedFile : includedFiles )
+
+// May give false positives if the files is named as module descriptor
+// but is not in the root of the archive or in the versioned area
+// (and hence not actually a module descriptor).
+// That is fine since the modular Jar archiver will gracefully
+// handle such case.
+// And also such case is unlikely to happen as file ending
+// with "module-info.class" is unlikely to be included in Jar file
+// unless it is a module descriptor.
+boolean containsModuleDescriptor =
+Arrays.stream( includedFiles ).anyMatch( p -> p.endsWith(
MODULE_DESCRIPTOR_FILE_NAME ) );
+
+if ( detectMultiReleaseJar && Arrays.stream( includedFiles ).anyMatch(
p -> p.startsWith( "META-INF" + SEPARATOR
++ "versions" + SEPARATOR ) ) )
{
-// May give false positives if the files is named as module
descriptor
-// but is not in the root of the archive or in the versioned area
-// (and hence not actually a module descriptor).
-// That is fine since the modular Jar archiver will gracefully
-// handle such case.
-// And also such case is unlikely to happen as file ending
-// with "module-info.class" is unlikely to be included in Jar file
-// unless it is a module descriptor.
-if ( includedFile.endsWith( MODULE_DESCRIPTOR_FILE_NAME ) )
-{
-containsModuleDescriptor = true;
-break;
-}
+getLog().debug( "Adding 'Multi-Release: true' manifest entry." );
+archive.addManifestEntry( "Multi-Release", "true" );
}
String archiverName = containsModuleDescriptor ? "mjar" : "jar";
Review Comment:
`mjar` is for detecting a "Modular JAR", it contains a module descriptor
(`module-info.class`), but it can be a normal "Modular JAR" (the module
descriptor is located in the root) or a "Multi-Release Modular JAR" (the module
descriptor is located in the versioned area).
Here, we are trying to detect if the versioned area exists, independently if
it contains a module descriptor or not.
--
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
[GitHub] [maven-jar-plugin] slawekjaranowski commented on a diff in pull request #57: [MJAR-292] - Detect MRJAR and add Multi-Release manifest entry
slawekjaranowski commented on code in PR #57:
URL: https://github.com/apache/maven-jar-plugin/pull/57#discussion_r1085228950
##
src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java:
##
@@ -225,23 +237,24 @@ public File createArchive()
jarContentFileSet.setIncludes( Arrays.asList( getIncludes() ) );
jarContentFileSet.setExcludes( Arrays.asList( getExcludes() ) );
-boolean containsModuleDescriptor = false;
String[] includedFiles = fileSetManager.getIncludedFiles(
jarContentFileSet );
-for ( String includedFile : includedFiles )
+
+// May give false positives if the files is named as module descriptor
+// but is not in the root of the archive or in the versioned area
+// (and hence not actually a module descriptor).
+// That is fine since the modular Jar archiver will gracefully
+// handle such case.
+// And also such case is unlikely to happen as file ending
+// with "module-info.class" is unlikely to be included in Jar file
+// unless it is a module descriptor.
+boolean containsModuleDescriptor =
+Arrays.stream( includedFiles ).anyMatch( p -> p.endsWith(
MODULE_DESCRIPTOR_FILE_NAME ) );
Review Comment:
I would like to move this lines to pleace where is used about lines 260
##
src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java:
##
@@ -225,23 +237,24 @@ public File createArchive()
jarContentFileSet.setIncludes( Arrays.asList( getIncludes() ) );
jarContentFileSet.setExcludes( Arrays.asList( getExcludes() ) );
-boolean containsModuleDescriptor = false;
String[] includedFiles = fileSetManager.getIncludedFiles(
jarContentFileSet );
-for ( String includedFile : includedFiles )
+
+// May give false positives if the files is named as module descriptor
+// but is not in the root of the archive or in the versioned area
+// (and hence not actually a module descriptor).
+// That is fine since the modular Jar archiver will gracefully
+// handle such case.
+// And also such case is unlikely to happen as file ending
+// with "module-info.class" is unlikely to be included in Jar file
+// unless it is a module descriptor.
+boolean containsModuleDescriptor =
+Arrays.stream( includedFiles ).anyMatch( p -> p.endsWith(
MODULE_DESCRIPTOR_FILE_NAME ) );
+
+if ( detectMultiReleaseJar && Arrays.stream( includedFiles ).anyMatch(
p -> p.startsWith( "META-INF" + SEPARATOR
++ "versions" + SEPARATOR ) ) )
{
-// May give false positives if the files is named as module
descriptor
-// but is not in the root of the archive or in the versioned area
-// (and hence not actually a module descriptor).
-// That is fine since the modular Jar archiver will gracefully
-// handle such case.
-// And also such case is unlikely to happen as file ending
-// with "module-info.class" is unlikely to be included in Jar file
-// unless it is a module descriptor.
-if ( includedFile.endsWith( MODULE_DESCRIPTOR_FILE_NAME ) )
-{
-containsModuleDescriptor = true;
-break;
-}
+getLog().debug( "Adding 'Multi-Release: true' manifest entry." );
+archive.addManifestEntry( "Multi-Release", "true" );
}
String archiverName = containsModuleDescriptor ? "mjar" : "jar";
Review Comment:
Should we also use `mjar` as archiver name when detect in steps above that
is Multi-Release?
I don't know what is difference between `mjar` and `jar` archiver ...
##
src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java:
##
@@ -225,23 +237,24 @@ public File createArchive()
jarContentFileSet.setIncludes( Arrays.asList( getIncludes() ) );
jarContentFileSet.setExcludes( Arrays.asList( getExcludes() ) );
-boolean containsModuleDescriptor = false;
String[] includedFiles = fileSetManager.getIncludedFiles(
jarContentFileSet );
-for ( String includedFile : includedFiles )
+
+// May give false positives if the files is named as module descriptor
+// but is not in the root of the archive or in the versioned area
+// (and hence not actually a module descriptor).
+// That is fine since the modular Jar archiver will gracefully
+// handle such case.
+// And also such case is unlikely to happen as file ending
+// with "module-info.class" is unlikely to be included in Jar file
+// unless it is a module descriptor.
+boolean containsModuleDescriptor =
+Arrays.stream( includedFiles ).anyMatch( p -> p.endsWith(
MODULE_DESCRIPTOR_FILE_NAME ) );
+
+if ( detectMultiReleaseJar &&
[GitHub] [maven-mvnd] gnodet commented on issue #770: Threads parameter is not working on Apple Silicon
gnodet commented on issue #770: URL: https://github.com/apache/maven-mvnd/issues/770#issuecomment-1401834119 I've set my `[USER_HOME]/.m2/mvnd.properties` to add `mvnd.threads=0.5C` and it works fine for me. Can you check your environment maybe using `set | grep MAVEN` ? _mvnd_ also checks the `[PROJECT_HOME]/.mvn/mvnd.properties` and `[MVND_HOME]/conf/mvnd.properties`... -- 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-92) Use https in license links of generated files
[ https://issues.apache.org/jira/browse/MWRAPPER-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680176#comment-17680176 ] Michael Osipov edited comment on MWRAPPER-92 at 1/24/23 11:29 AM: -- There is no consent whether this is OK from ASF's point of view because this is a change in license and the license needs to be retained 1:1. It not only applies to this subproject, but all of them. was (Author: michael-o): There is no consent whether this is OK from ASF's point of view because this is a change in license and the license needs to be retained 1:1. It not only applies to this subproject, but all. > Use https in license links of generated files > - > > Key: MWRAPPER-92 > URL: https://issues.apache.org/jira/browse/MWRAPPER-92 > Project: Maven Wrapper > Issue Type: Task > Components: Maven Wrapper Plugin >Affects Versions: 3.1.1 >Reporter: Michael Keppler >Priority: Trivial > > The generated scripts mvnw and mvnw.cmd contain links to the Apache license > texts. Please make them use https instead of http. > https is already used for the same links in other generated files, like > maven-wrapper.properties (and should generally be the default nowadays). > Found because we monitor our own repositories with > https://github.com/spring-io/nohttp -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-mvnd] gnodet closed issue #756: Bash Completions Kills Shell (Mac/Homebrew)
gnodet closed issue #756: Bash Completions Kills Shell (Mac/Homebrew) URL: https://github.com/apache/maven-mvnd/issues/756 -- 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
[GitHub] [maven-mvnd] gnodet commented on issue #756: Bash Completions Kills Shell (Mac/Homebrew)
gnodet commented on issue #756: URL: https://github.com/apache/maven-mvnd/issues/756#issuecomment-1401726773 The home-brew package sources are at https://github.com/mvndaemon/homebrew-mvnd/tree/master. I can't find where a file such as the one you have would come from, but I have the same locally, so I suppose it's generated by home-brew during the installation process. So I don't think the hardcoded version is a problem, as it will be updated by home-brew. I think the problem is that the `/usr/local/Cellar/mvnd/0.8.2/libexec/bin/mvnd-bash-completion.bash` has no executable flag. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MWRAPPER-92) Use https in license links of generated files
[ https://issues.apache.org/jira/browse/MWRAPPER-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MWRAPPER-92: --- Issue Type: Task (was: Bug) > Use https in license links of generated files > - > > Key: MWRAPPER-92 > URL: https://issues.apache.org/jira/browse/MWRAPPER-92 > Project: Maven Wrapper > Issue Type: Task > Components: Maven Wrapper Plugin >Affects Versions: 3.1.1 >Reporter: Michael Keppler >Priority: Trivial > > The generated scripts mvnw and mvnw.cmd contain links to the Apache license > texts. Please make them use https instead of http. > https is already used for the same links in other generated files, like > maven-wrapper.properties (and should generally be the default nowadays). > Found because we monitor our own repositories with > https://github.com/spring-io/nohttp -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MWRAPPER-92) Use https in license links of generated files
[ https://issues.apache.org/jira/browse/MWRAPPER-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680176#comment-17680176 ] Michael Osipov commented on MWRAPPER-92: There is no consent whether this is OK from ASF's point of view because this is a change in license and the license needs to be retained 1:1. It not only applies to this subproject, but all. > Use https in license links of generated files > - > > Key: MWRAPPER-92 > URL: https://issues.apache.org/jira/browse/MWRAPPER-92 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Plugin >Affects Versions: 3.1.1 >Reporter: Michael Keppler >Priority: Trivial > > The generated scripts mvnw and mvnw.cmd contain links to the Apache license > texts. Please make them use https instead of http. > https is already used for the same links in other generated files, like > maven-wrapper.properties (and should generally be the default nowadays). > Found because we monitor our own repositories with > https://github.com/spring-io/nohttp -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MWRAPPER-92) Use https in license links of generated files
Michael Keppler created MWRAPPER-92: --- Summary: Use https in license links of generated files Key: MWRAPPER-92 URL: https://issues.apache.org/jira/browse/MWRAPPER-92 Project: Maven Wrapper Issue Type: Bug Components: Maven Wrapper Plugin Affects Versions: 3.1.1 Reporter: Michael Keppler The generated scripts mvnw and mvnw.cmd contain links to the Apache license texts. Please make them use https instead of http. https is already used for the same links in other generated files, like maven-wrapper.properties (and should generally be the default nowadays). Found because we monitor our own repositories with https://github.com/spring-io/nohttp -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-mvnd] gnodet merged pull request #717: Try native image then fallback to pure java version
gnodet merged PR #717: URL: https://github.com/apache/maven-mvnd/pull/717 -- 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
[GitHub] [maven-mvnd] gnodet merged pull request #769: Attempt at moving mvn as first class citizen in mvnd distribution, #392
gnodet merged PR #769: URL: https://github.com/apache/maven-mvnd/pull/769 -- 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
[GitHub] [maven-mvnd] gnodet closed issue #777: How to change jdk version in mac os
gnodet closed issue #777: How to change jdk version in mac os URL: https://github.com/apache/maven-mvnd/issues/777 -- 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
[GitHub] [maven-mvnd] gnodet closed issue #773: The built-in 4.0.0 version of maven will invalidate the flatten-maven-plugin plugin
gnodet closed issue #773: The built-in 4.0.0 version of maven will invalidate the flatten-maven-plugin plugin URL: https://github.com/apache/maven-mvnd/issues/773 -- 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
[GitHub] [maven-mvnd] gnodet commented on issue #773: The built-in 4.0.0 version of maven will invalidate the flatten-maven-plugin plugin
gnodet commented on issue #773: URL: https://github.com/apache/maven-mvnd/issues/773#issuecomment-1401626403 Closing as a duplicate -- 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] (MCHECKSTYLE-425) Checkstyle runs fail with "Path contains invalid character" since 3.2.0
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680135#comment-17680135 ] Magnus Reftel commented on MCHECKSTYLE-425: --- Attaching stacktrace from mvn clean validate -X with latest from master.[^maven-checkstyle-plugin_stacktrace.txt] > Checkstyle runs fail with "Path contains invalid character" since 3.2.0 > --- > > Key: MCHECKSTYLE-425 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-425 > Project: Maven Checkstyle Plugin > Issue Type: Bug >Affects Versions: 3.2.0 >Reporter: Magnus Reftel >Priority: Major > Attachments: maven-checkstyle-plugin_stacktrace.txt > > > The maven-checkstyle-plugin fails on maven projects whose file system path > contains the letter "ø" in versions 3.2.0, 3.2.1 and on master. Version 3.1.2 > works fine. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MCHECKSTYLE-425) Checkstyle runs fail with "Path contains invalid character" since 3.2.0
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Magnus Reftel updated MCHECKSTYLE-425: -- Attachment: maven-checkstyle-plugin_stacktrace.txt > Checkstyle runs fail with "Path contains invalid character" since 3.2.0 > --- > > Key: MCHECKSTYLE-425 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-425 > Project: Maven Checkstyle Plugin > Issue Type: Bug >Affects Versions: 3.2.0 >Reporter: Magnus Reftel >Priority: Major > Attachments: maven-checkstyle-plugin_stacktrace.txt > > > The maven-checkstyle-plugin fails on maven projects whose file system path > contains the letter "ø" in versions 3.2.0, 3.2.1 and on master. Version 3.1.2 > works fine. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCHECKSTYLE-425) Checkstyle runs fail with "Path contains invalid character" since 3.2.0
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680133#comment-17680133 ] Magnus Reftel commented on MCHECKSTYLE-425: --- Bisecting shows that the issue was introduced with commit 3bc2ec01414f39861938dd9accae7225eb48582b. > Checkstyle runs fail with "Path contains invalid character" since 3.2.0 > --- > > Key: MCHECKSTYLE-425 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-425 > Project: Maven Checkstyle Plugin > Issue Type: Bug >Affects Versions: 3.2.0 >Reporter: Magnus Reftel >Priority: Major > > The maven-checkstyle-plugin fails on maven projects whose file system path > contains the letter "ø" in versions 3.2.0, 3.2.1 and on master. Version 3.1.2 > works fine. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (SUREFIRE-2144) Using JUnit4 TestSuite to create test dynamically, synthetic initializationError failure breaks Jenkins test history
[
https://issues.apache.org/jira/browse/SUREFIRE-2144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680131#comment-17680131
]
Geoff Soutter edited comment on SUREFIRE-2144 at 1/24/23 8:04 AM:
--
OK, so I made a local version of JUnit with the ErrorRunningReporter replaced
with throw {{RuntimeException("PREVENTING ...". e)}} in both
{{SuiteMethodBuilder}} and {{{}AllDefaultPossibilitiesBuilder{}}}. When run
directly from IDEA this reports {{{}"No tests were found"{}}}, which is what we
want - no fake tests created.
But when tested with Surefire, it still synthesizes a slightly different fake
test. In this case, we can see the {{initializationFailed}} disappears which
makes me think this fake test was being created by Surefire rather than JUnit -
presumably in {{executeTestSet}} as above.
{code:java}
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.918 s
<<< FAILURE! - in com.project.package.MySuite
[ERROR] com.project.package.MySuite Time elapsed: 0.912 s <<< ERROR!
java.lang.RuntimeException: PREVENTING AllDefaultPossibilitiesBuilder
ErrorReportingRunner
at
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.safeRunnerForClass(AllDefaultPossibilitiesBuilder.java:63)
at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:362)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
Caused by: java.lang.RuntimeException: PREVENTING SuiteMethodBuilder
ErrorReportingRunner
at
org.junit.internal.builders.SuiteMethodBuilder.safeRunnerForClass(SuiteMethodBuilder.java:32)
at
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
at
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.safeRunnerForClass(AllDefaultPossibilitiesBuilder.java:59)
... 9 more
Caused by: java.lang.RuntimeException: java.net.ConnectException: Connection
refused (Connection refused)
{code}
So it seems fixing this problem would require changes in both JUnit and
Surefire. Sigh.
was (Author: gsoutter):
OK, so I made a local version of JUnit with the ErrorRunningReporter replaced
with throw {{RuntimeException("PREVENTING ...". e)}} in both
{{SuiteMethodBuilder}} and {{{}AllDefaultPossibilitiesBuilder{}}}. When run
directly from IDEA this reports {{{}"No tests were found"{}}}.
But when tested with Surefire, it still synthesizes a slightly different fake
test. In this case, we can see the {{initializationFailed}} disappears which
makes me think this fake test was being created by Surefire rather than JUnit -
presumably in {{executeTestSet}} as above.
{code:java}
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.918 s
<<< FAILURE! - in com.project.package.MySuite
[ERROR] com.project.package.MySuite Time elapsed: 0.912 s <<< ERROR!
java.lang.RuntimeException: PREVENTING AllDefaultPossibilitiesBuilder
ErrorReportingRunner
at
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.safeRunnerForClass(AllDefaultPossibilitiesBuilder.java:63)
at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:362)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
Caused by: java.lang.RuntimeException: PREVENTING SuiteMethodBuilder
ErrorReportingRunner
at
org.junit.internal.builders.SuiteMethodBuilder.safeRunnerForClass(SuiteMethodBuilder.java:32)
at
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
at
[jira] [Commented] (SUREFIRE-2144) Using JUnit4 TestSuite to create test dynamically, synthetic initializationError failure breaks Jenkins test history
[
https://issues.apache.org/jira/browse/SUREFIRE-2144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680131#comment-17680131
]
Geoff Soutter commented on SUREFIRE-2144:
-
OK, so I made a local version of JUnit with the ErrorRunningReporter replaced
with throw {{RuntimeException("PREVENTING ...". e)}} in both
{{SuiteMethodBuilder}} and {{{}AllDefaultPossibilitiesBuilder{}}}. When run
directly from IDEA this reports {{{}"No tests were found"{}}}.
But when tested with Surefire, it still synthesizes a slightly different fake
test. In this case, we can see the {{initializationFailed}} disappears which
makes me think this fake test was being created by Surefire rather than JUnit -
presumably in {{executeTestSet}} as above.
{code:java}
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.918 s
<<< FAILURE! - in com.project.package.MySuite
[ERROR] com.project.package.MySuite Time elapsed: 0.912 s <<< ERROR!
java.lang.RuntimeException: PREVENTING AllDefaultPossibilitiesBuilder
ErrorReportingRunner
at
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.safeRunnerForClass(AllDefaultPossibilitiesBuilder.java:63)
at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:362)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
Caused by: java.lang.RuntimeException: PREVENTING SuiteMethodBuilder
ErrorReportingRunner
at
org.junit.internal.builders.SuiteMethodBuilder.safeRunnerForClass(SuiteMethodBuilder.java:32)
at
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
at
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.safeRunnerForClass(AllDefaultPossibilitiesBuilder.java:59)
... 9 more
Caused by: java.lang.RuntimeException: java.net.ConnectException: Connection
refused (Connection refused)
{code}
So it seems fixing this problem would require changes in both JUnit and
Surefire. Sigh.
> Using JUnit4 TestSuite to create test dynamically, synthetic
> initializationError failure breaks Jenkins test history
>
>
> Key: SUREFIRE-2144
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2144
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.22.2
>Reporter: Geoff Soutter
>Priority: Major
>
> My team is dynamically creating tests using the JUnit3/4 static suite method
> + TestSuite API
> {code}
> public static junit.framework.Test suite() {
> TestSuite testSuite = new TestSuite(xxx);
> for (Test test: tests) {
> testSuite.addTest(yyy);
> }
> return testSuite;
> }
> {code}
> and then running this using Jenkins CI with Surefire.
> There is a nasty failure pattern which periodically deletes the Jenkins test
> history - it resets the Age of all tests in Jenkins back to 1. The history /
> Age report in Jenkins is key for us as it reveals which commit caused the
> failure. We definitely do not want to lose that information.
> The failure pattern goes like this:
> * many tests are running fine, with some failures
> * a commit is made, CI triggers, Jenkins runs surefire.
> ** This results in a problem inside the suite() method, which throws a
> RuntimeException. This is the dynamic test creation phase, before any tests
> are run.
> ** This results in Surefire reporting a successful run of a single
> "fake/synthetic" test which is reported as failed.
> * a commit is made to fix the test creation phase, CI again triggeers,
> Jenkins runs surefire
> ** This results in many tests again running fine, with the same failures as
> before
> ** However, Jenkins now reports all the old failures from the first step as
> Age 1 - all the Age history is lost
> The synthetic test failure looks like so:
> {code}
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 1.064 s <<< FAILURE! - in com.company.package.MySuite
> [ERROR] initializationError(com.company.package.MySuite) Time elapsed: 0.019
> s <<< ERROR!
> java.lang.RuntimeException: java.net.ConnectException: Connection
