[GitHub] [maven] rfscholte commented on pull request #636: Improve startup scripts
rfscholte commented on pull request #636: URL: https://github.com/apache/maven/pull/636#issuecomment-999358807 Must also end up in https://github.com/apache/maven-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
[GitHub] [maven] rfscholte commented on pull request #637: [MNG-7193] Introduce MAVEN_ARGS environment variable
rfscholte commented on pull request #637: URL: https://github.com/apache/maven/pull/637#issuecomment-999358494 Must also end up in https://github.com/apache/maven-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] [Commented] (DOXIASITETOOLS-227) Throwing "new ParseException(message)" shows message with "line [-1]"
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463620#comment-17463620
]
Abel Salgado Romero commented on DOXIASITETOOLS-227:
Thanks a lot!
Already validated, I am overriding the dependencies manually like. But I
wonder, is this something we can openly suggest to users of our doxia module?
Or just a "run at your own risk" workaround?
{{
org.apache.maven.plugins
maven-site-plugin
3.9.1
true
true
false
en
UTF-8
UTF-8
font
coderay
style
2
org.asciidoctor
asciidoctor-maven-plugin
${asciidoctor.maven.plugin.version}
org.apache.maven.doxia
doxia-site-renderer
1.11.2-SNAPSHOT
org.apache.maven.doxia
doxia-core
1.11.1
}}
> Throwing "new ParseException(message)" shows message with "line [-1]"
> -
>
> Key: DOXIASITETOOLS-227
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-227
> Project: Maven Doxia Sitetools
> Issue Type: Bug
> Components: Site renderer
>Affects Versions: 1.9.1
>Reporter: Abel Salgado Romero
>Assignee: Michael Osipov
>Priority: Minor
> Labels: intern
> Fix For: 1.10
>
>
> When throwing a 'org.apache.maven.doxia.parser.ParseException' from a Doxia
> module indicating only a message or source exception a message pointing to
> line -1 is show in console.
> Exemple:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.7.1:site (default-cli) on
> project asciidoc-maven-site-example: Error parsing
> '/home/asalgadr/github/asciidoctor-maven-examples/asciidoc-maven-site-example/src/site/asciidoc/article.adoc':
> line [-1] Found 1 issue(s) of severity DEBUG or higher during rendering ->
> [Help 1]
>
> I would expect that in case the line is not initialized, no reference to it
> is shown in the console.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MWRAPPER-43) Download of jar must be quiet by default
[
https://issues.apache.org/jira/browse/MWRAPPER-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463610#comment-17463610
]
Herve Boutemy commented on MWRAPPER-43:
---
out of curiosity: how do you test with/without wget and curl?
are you basically installing/removing them on your Linux box? or did you
imagine a trick to disable them without being root?
it could help us doing more complete integration tests...
> Download of jar must be quiet by default
>
>
> Key: MWRAPPER-43
> URL: https://issues.apache.org/jira/browse/MWRAPPER-43
> Project: Maven Wrapper
> Issue Type: Improvement
> Components: Maven Wrapper Scripts
>Affects Versions: 3.1.0
>Reporter: Jorge Solórzano
>Assignee: Herve Boutemy
>Priority: Normal
> Fix For: 3.1.1
>
>
> By default, the wrapper must be quiet, if the _maven-wrapper.jar_ is not
> found the scripts try to download the jar using {*}wget{*}, {*}curl{*}, or
> the {*}MavenWrapperDownloader{*}.java.
> The download process should only print the output when the +*MVNW_VERBOSE*+
> is set to true.
> Current output for *wget* when the maven-wrapper.jar is missing:
> {noformat}
> ./mvnw clean
> --2021-12-21 11:52:43--
> https://repo.maven.apache.org/maven2/org/apache/maven/wrapper/maven-wrapper/3.1.0/maven-wrapper-3.1.0.jar
> Resolving repo.maven.apache.org (repo.maven.apache.org)... 151.101.132.215
> Connecting to repo.maven.apache.org
> (repo.maven.apache.org)|151.101.132.215|:443... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 58727 (57K) [application/java-archive]
> Saving to: '/home/wrapper/api/.mvn/wrapper/maven-wrapper.jar'
> /home/jorsol/Trabajo/conf-worksp
> 100%[==>] 57,35K
> --.-KB/sin 0,007s
> 2021-12-21 11:52:44 (8,13 MB/s) -
> '/home/wrapper/api/.mvn/wrapper/maven-wrapper.jar' saved [58727/58727]
> 11:52:45.544 [INFO] Scanning for projects...
> ...
> {noformat}
> Current output for *curl* the maven-wrapper.jar is missing:
> {noformat}
> ./mvnw clean
> % Total% Received % Xferd Average Speed TimeTime Time
> Current
> Dload Upload Total SpentLeft Speed
> 100 58727 100 587270 0 1303k 0 --:--:-- --:--:-- --:--:-- 1303k
> 12:02:23.007 [INFO] Scanning for projects...
> ...
> {noformat}
> Current output for *MavenWrapperDownloader* when the maven-wrapper.jar is
> missing:
> {noformat}
> ./mvnw clean
> - Downloader started
> - Using base directory: /home/wrapper/api
> - Downloading from:
> https://repo.maven.apache.org/maven2/org/apache/maven/wrapper/maven-wrapper/3.1.0/maven-wrapper-3.1.0.jar
> - Downloading to: /home/wrapper/api/.mvn/wrapper/maven-wrapper.jar
> Done
> 11:50:21.599 [INFO] Scanning for projects...
> ...
> {noformat}
> Everything between the _./mvnw_ and the first _INFO_ is just unwanted
> verbosity.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MWRAPPER-42) maven-wrapper fails to self-update maven-wrapper.jar
[ https://issues.apache.org/jira/browse/MWRAPPER-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463607#comment-17463607 ] Herve Boutemy commented on MWRAPPER-42: --- notice that an IT is small enough to contribute without CLA: CLA will be useful later, when you'll contribute more than just this issue :D > maven-wrapper fails to self-update maven-wrapper.jar > > > Key: MWRAPPER-42 > URL: https://issues.apache.org/jira/browse/MWRAPPER-42 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: Jeremy Norris >Priority: Major > Fix For: 3.1.1 > > > In cases where users do not check-in the maven-wrapper.jar into their > repositories, after executing `mvn wrapper:wrapper -Dtype=script` to update, > the newly updated `mvnw` script will continue to use an older version of > `.mvn/wrapper/maven-wrapper.jar` that was previously downloaded. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-surefire] findepi commented on pull request #407: [SUREFIRE-1967] Fix parallel test ordering to prevent high resource consumption
findepi commented on pull request #407: URL: https://github.com/apache/maven-surefire/pull/407#issuecomment-999317820 @slawekjaranowski thanks, done -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7366) Maven downloading log4j version not specified in POM when building the Project.
[ https://issues.apache.org/jira/browse/MNG-7366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463597#comment-17463597 ] Srinivasan L commented on MNG-7366: --- Thanks [~mthmulders] got it. But I was curious why Maven is downloading Log4j when no Dependency specified in the Project POM. > Maven downloading log4j version not specified in POM when building the > Project. > --- > > Key: MNG-7366 > URL: https://issues.apache.org/jira/browse/MNG-7366 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories, Dependencies >Affects Versions: 3.8.4 >Reporter: Srinivasan L >Priority: Critical > Attachments: maven log4j issue.png > > > Maven downloading log4j version not specified in POM when building the > Project. > In POM i have updated my log4j to log4j core 2.16.0 to fix the Log4j > Vulnerability with Older version. But even after changing the Version Maven > is downloading 1.2.12 and 1.2.17 version of Log4j when running the build. > I'm not seeing these version even in the dependency tree of my Project. > Please help to fix this issue as its a Critical Security Issue. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-checkstyle-plugin] dependabot[bot] opened a new pull request #61: Bump doxiaVersion from 1.10 to 1.11.1
dependabot[bot] opened a new pull request #61: URL: https://github.com/apache/maven-checkstyle-plugin/pull/61 Bumps `doxiaVersion` from 1.10 to 1.11.1. Updates `doxia-site-renderer` from 1.10 to 1.11.1 Commits https://github.com/apache/maven-doxia-sitetools/commit/1f9fcf561c3a4e7ccd39dfd49bb905a296bfac1b;>1f9fcf5 [maven-release-plugin] prepare release doxia-sitetools-1.11.1 https://github.com/apache/maven-doxia-sitetools/commit/ff4b0597b62507ed2e706a7d9abc978e47ead55f;>ff4b059 prepare for next development iteration 1.11.1-SNAPSHOT https://github.com/apache/maven-doxia-sitetools/commit/a264e00c14bbc61bf710fd484a750fb6bff1f51a;>a264e00 [DOXIASITETOOLS-235] Upgrade Maven Doxia to 1.11.1 https://github.com/apache/maven-doxia-sitetools/commit/6fccb6143aeb27a8e28c8cbcd62cc4cbcb8d952b;>6fccb61 [maven-release-plugin] prepare for next development iteration https://github.com/apache/maven-doxia-sitetools/commit/f31512005085c6d39247f4619738a9f7f955a8e6;>f315120 [maven-release-plugin] prepare release doxia-sitetools-1.11 https://github.com/apache/maven-doxia-sitetools/commit/02d1a3cb2afafac22c2af7527f02d20fbda3de07;>02d1a3c [DOXIASITETOOLS-235] Upgrade Maven Doxia to 1.11.1 https://github.com/apache/maven-doxia-sitetools/commit/cabe7d304f9e75ea1e40f1563854962132cb9a9a;>cabe7d3 [DOXIASITETOOLS-236] Deprecate Doxia Sitetools Doc Renderer https://github.com/apache/maven-doxia-sitetools/commit/eccba710e039df756fca982732e2a1e56a41f6b4;>eccba71 [DOXIASITETOOLS-234] improve doc site.xml inheritence vs interpolation https://github.com/apache/maven-doxia-sitetools/commit/6a092264ae0919d1b3b56a47c097634238ce5db6;>6a09226 update CI url https://github.com/apache/maven-doxia-sitetools/commit/b9944510be571b85ce6d7b3998a3215bba6d6fc3;>b994451 [maven-release-plugin] prepare for next development iteration See full diff in https://github.com/apache/maven-doxia-sitetools/compare/doxia-sitetools-1.10...doxia-sitetools-1.11.1;>compare view Updates `doxia-integration-tools` from 1.10 to 1.11.1 Commits https://github.com/apache/maven-doxia-sitetools/commit/1f9fcf561c3a4e7ccd39dfd49bb905a296bfac1b;>1f9fcf5 [maven-release-plugin] prepare release doxia-sitetools-1.11.1 https://github.com/apache/maven-doxia-sitetools/commit/ff4b0597b62507ed2e706a7d9abc978e47ead55f;>ff4b059 prepare for next development iteration 1.11.1-SNAPSHOT https://github.com/apache/maven-doxia-sitetools/commit/a264e00c14bbc61bf710fd484a750fb6bff1f51a;>a264e00 [DOXIASITETOOLS-235] Upgrade Maven Doxia to 1.11.1 https://github.com/apache/maven-doxia-sitetools/commit/6fccb6143aeb27a8e28c8cbcd62cc4cbcb8d952b;>6fccb61 [maven-release-plugin] prepare for next development iteration https://github.com/apache/maven-doxia-sitetools/commit/f31512005085c6d39247f4619738a9f7f955a8e6;>f315120 [maven-release-plugin] prepare release doxia-sitetools-1.11 https://github.com/apache/maven-doxia-sitetools/commit/02d1a3cb2afafac22c2af7527f02d20fbda3de07;>02d1a3c [DOXIASITETOOLS-235] Upgrade Maven Doxia to 1.11.1 https://github.com/apache/maven-doxia-sitetools/commit/cabe7d304f9e75ea1e40f1563854962132cb9a9a;>cabe7d3 [DOXIASITETOOLS-236] Deprecate Doxia Sitetools Doc Renderer https://github.com/apache/maven-doxia-sitetools/commit/eccba710e039df756fca982732e2a1e56a41f6b4;>eccba71 [DOXIASITETOOLS-234] improve doc site.xml inheritence vs interpolation https://github.com/apache/maven-doxia-sitetools/commit/6a092264ae0919d1b3b56a47c097634238ce5db6;>6a09226 update CI url https://github.com/apache/maven-doxia-sitetools/commit/b9944510be571b85ce6d7b3998a3215bba6d6fc3;>b994451 [maven-release-plugin] prepare for next development iteration See full diff in https://github.com/apache/maven-doxia-sitetools/compare/doxia-sitetools-1.10...doxia-sitetools-1.11.1;>compare view Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major
[GitHub] [maven-surefire] dependabot[bot] opened a new pull request #413: Bump htmlunit from 2.33 to 2.56.0
dependabot[bot] opened a new pull request #413: URL: https://github.com/apache/maven-surefire/pull/413 Bumps [htmlunit](https://github.com/HtmlUnit/htmlunit) from 2.33 to 2.56.0. Release notes Sourced from https://github.com/HtmlUnit/htmlunit/releases;>htmlunit's releases. HtmlUnit 2.56.0 Highlights Chrome/Edge 96 Firefox 95 FF78 deprecated - use FF_ESR instead FF_ESR is in sync with Firefox 91 ESR improved css parser (rgb/a hsl/a colors) various Rhino updates Please have a look at the https://htmlunit.sourceforge.io/changes-report.html#a2.56.0;>full release notes for details about this release. HtmlUnit 2.55.0 Highlights Chrome/Edge 95 Firefox 94 xerces 2.12.1 various rhino/core-js fixes socks proxy authentication support the usual bunch of fixes Please have a look at the https://htmlunit.sourceforge.io/changes-report.html#a2.55.0;>full release notes for details about this release. HtmlUnit 2.54.0 Highlights Chrome/Edge 94 Firefox 93 various core-js optimizations make threading more flexible Xpath case sensitive processing was broken if an string inside the xpath contains or @ bunch of fixes Please have a look at the https://htmlunit.sourceforge.io/changes-report.html#a2.54.0;>full release notes for details about this release. HtmlUnit 2.53.0 Highlights Chrome/Edge 93 Firefox 92 XMLHttpRequest.send() has to serialize the body value if it is Document Finally support getting and setting style properties via elem.style['property-name'] notation bunch of fixes for URLSearchParams Please have a look at the https://htmlunit.sourceforge.io/changes-report.html#a2.53.0;>full release notes for details about this release. HtmlUnit 2.52.0 Highlights the usual bugfixes Firefox 90 updates from Rhino many java.awt dependencies removed (by implementing our own simple 2D graphics) inline styles are now parsed by the htmlunit-cssparser ... (truncated) Commits https://github.com/HtmlUnit/htmlunit/commit/ee34e0e3d1eaeaa94ed38e06e141df5b0df21bf7;>ee34e0e prepare 2.56.0 https://github.com/HtmlUnit/htmlunit/commit/215355febd2800190a8464e53b55f18535a3098f;>215355f fix charCode/keyCode for KeyPressEvent's when simulating Firefox https://github.com/HtmlUnit/htmlunit/commit/400ddaba9b086694b2f2f3b2742922a55a48b5b9;>400ddab fix charCode/keyCode for KeyPressEvent's when simulating Firefox https://github.com/HtmlUnit/htmlunit/commit/ba008e3d37afb2d58f15c1d087b4b0b168803804;>ba008e3 give it again a try https://github.com/HtmlUnit/htmlunit/commit/60ed501b8cdfc97212ae82cbcef84d82aa1bd992;>60ed501 remove no longer needed annotation https://github.com/HtmlUnit/htmlunit/commit/c9adc1c01a6c32c74d5d3261955c070d00d060e8;>c9adc1c update dependencies https://github.com/HtmlUnit/htmlunit/commit/6e5f7f343cf20bca06e8dd99f3f32440ea8aad27;>6e5f7f3 adjust for latest core-js https://github.com/HtmlUnit/htmlunit/commit/9716d20db60011eed999a1550b21ade349bd5c37;>9716d20 document last core-js changes https://github.com/HtmlUnit/htmlunit/commit/019d15d5a3f02c312744cccd07fe086f8ce5dcc2;>019d15d log4j 2.15.0 https://github.com/HtmlUnit/htmlunit/commit/edcfa78061437af1a567c3a096cd254ac57fa869;>edcfa78 typo Additional commits viewable in https://github.com/HtmlUnit/htmlunit/compare/2.33...2.56.0;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore
[GitHub] [maven-invoker-plugin] dependabot[bot] opened a new pull request #84: Bump extra-enforcer-rules from 1.4 to 1.5.1
dependabot[bot] opened a new pull request #84: URL: https://github.com/apache/maven-invoker-plugin/pull/84 Bumps [extra-enforcer-rules](https://github.com/mojohaus/extra-enforcer-rules) from 1.4 to 1.5.1. Release notes Sourced from https://github.com/mojohaus/extra-enforcer-rules/releases;>extra-enforcer-rules's releases. 1.5.1 No changes Last release has issues with oss.sonatype.org so trying again 1.5.0 Bump log4j-api from 2.15.0 to 2.16.0 in /src/it/enforce-bytecode-version-multirelease (https://github-redirect.dependabot.com/mojohaus/extra-enforcer-rules/issues/154;>#154) https://github.com/dependabot;>@dependabot Bump log4j-api from 2.15.0 to 2.16.0 in /src/it/banduplicate-classes-fail-when-not-identical (https://github-redirect.dependabot.com/mojohaus/extra-enforcer-rules/issues/155;>#155) https://github.com/dependabot;>@dependabot Bump log4j-api from 2.15.0 to 2.16.0 in /src/it/banduplicate-classes-ignore-when-identical (https://github-redirect.dependabot.com/mojohaus/extra-enforcer-rules/issues/156;>#156) https://github.com/dependabot;>@dependabot Bump log4j-api from 2.15.0 to 2.16.0 in /src/it/banduplicate-classes-jdk9 (https://github-redirect.dependabot.com/mojohaus/extra-enforcer-rules/issues/157;>#157) https://github.com/dependabot;>@dependabot Bump mockito-core from 3.12.4 to 4.1.0 (https://github-redirect.dependabot.com/mojohaus/extra-enforcer-rules/issues/151;>#151) https://github.com/dependabot;>@dependabot Bump actions/setup-java from 2.3.1 to 2.4.0 (https://github-redirect.dependabot.com/mojohaus/extra-enforcer-rules/issues/153;>#153) https://github.com/dependabot;>@dependabot Bump mojo-parent from 63 to 65 (https://github-redirect.dependabot.com/mojohaus/extra-enforcer-rules/issues/152;>#152) https://github.com/dependabot;>@dependabot Bump actions/setup-java from 2.3.0 to 2.3.1 (https://github-redirect.dependabot.com/mojohaus/extra-enforcer-rules/issues/145;>#145) https://github.com/dependabot;>@dependabot Bug Fixes Bytecode version of multirelease metadata should be lower or equal to specified version (https://github-redirect.dependabot.com/mojohaus/extra-enforcer-rules/issues/158;>#158) https://github.com/Vlatombe;>@Vlatombe Commits https://github.com/mojohaus/extra-enforcer-rules/commit/da069393305d91ff1bf24fecd1725d145cf3a121;>da06939 [maven-release-plugin] prepare release extra-enforcer-rules-1.5.1 https://github.com/mojohaus/extra-enforcer-rules/commit/24c1b61b670f4ad6495762e6f86377ef783c733a;>24c1b61 [maven-release-plugin] prepare for next development iteration https://github.com/mojohaus/extra-enforcer-rules/commit/4e4e2db3df60fc8af22c877e38f27b391c6be1f8;>4e4e2db [maven-release-plugin] prepare release extra-enforcer-rules-1.5 https://github.com/mojohaus/extra-enforcer-rules/commit/5553dfc45a7cc4090b270b9bcd5d429804f8e7f4;>5553dfc fix IT test https://github.com/mojohaus/extra-enforcer-rules/commit/ecff4d7c5eae7d9e9e1f61a7cb9f43ffb06ea17c;>ecff4d7 Bump log4j-api in /src/it/enforce-bytecode-version-multirelease https://github.com/mojohaus/extra-enforcer-rules/commit/4db8e82362ebf79fd2ca373d38511c8ad0cf1cd1;>4db8e82 Merge pull request https://github-redirect.dependabot.com/mojohaus/extra-enforcer-rules/issues/155;>#155 from mojohaus/dependabot/maven/src/it/banduplicate-cl... https://github.com/mojohaus/extra-enforcer-rules/commit/b21d419d09def4665e0cc1209967e4d986ebfb13;>b21d419 Merge pull request https://github-redirect.dependabot.com/mojohaus/extra-enforcer-rules/issues/156;>#156 from mojohaus/dependabot/maven/src/it/banduplicate-cl... https://github.com/mojohaus/extra-enforcer-rules/commit/9aded1a52b48a1ca3b720e41a7a7251b2784f3ef;>9aded1a Merge pull request https://github-redirect.dependabot.com/mojohaus/extra-enforcer-rules/issues/157;>#157 from mojohaus/dependabot/maven/src/it/banduplicate-cl... https://github.com/mojohaus/extra-enforcer-rules/commit/90ac027afa09353989f9ba1173f49fe2dcd41404;>90ac027 Bytecode version of multirelease metadata should be lower or equal to specifi... https://github.com/mojohaus/extra-enforcer-rules/commit/0cdcfacfbfaa29c5c22ad5bfb669983748f1d36d;>0cdcfac Bump log4j-api in /src/it/banduplicate-classes-jdk9 Additional commits viewable in https://github.com/mojohaus/extra-enforcer-rules/compare/extra-enforcer-rules-1.4...extra-enforcer-rules-1.5.1;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[jira] [Comment Edited] (MENFORCER-399) requireVariable = requireProperty or requireEnvironmentVariable
[
https://issues.apache.org/jira/browse/MENFORCER-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458119#comment-17458119
]
Hüseyin Kartal edited comment on MENFORCER-399 at 12/22/21, 12:54 AM:
--
No, i created a pom for demo.
For explanation. It is possible to use the value of an environment variable or
a property in a pom just as follows. It doesn't matter if VAR is an environment
variable or a property.
{quote}{{${VAR}}}
{quote}
But it's not possible to enforce this behaviour. That ${VAR} is set.
To test this with the demo pom, just define environment like:
{quote}export VAR=environment
{quote}
Or pass the property like:
{quote}{{mvn install -DVAR=property}}
{quote}
It is not possible to handle both cases with the enforcer.
was (Author: hsyn):
I created a pom for demo.
You can define an environment variable and/or pass a property to that and the
value will be used for the property "variable".
{quote}{{${VAR}}}
{quote}
But it's not possible to enforce this behaviour. That ${VAR} is set.
To test just define envioronment like:
{quote}export VAR=environment
{quote}
Or pass the property like:
{quote}{{mvn install -DVAR=property}}
{quote}
> requireVariable = requireProperty or requireEnvironmentVariable
> ---
>
> Key: MENFORCER-399
> URL: https://issues.apache.org/jira/browse/MENFORCER-399
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Standard Rules
>Affects Versions: 3.0.0
>Reporter: Hüseyin Kartal
>Priority: Major
> Attachments: pom.xml
>
>
> As far a i know maven doesn't care where a value for ${variable} comes from.
> In a pom you can access a env.variable or a property by ${variable}.
> Also in some system the value is provided by an environment variable like
> CICD or by a property maybe a dev environment.
> I would suggest a new standard rule "requireVariable" which just look like
> maven for a value for this variable by property or environment.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-javadoc-plugin] slachiewicz merged pull request #112: Bump plexus-archiver from 4.2.5 to 4.2.6
slachiewicz merged pull request #112: URL: https://github.com/apache/maven-javadoc-plugin/pull/112 -- 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] (SUREFIRE-1916) thread blocked freezing progress
[ https://issues.apache.org/jira/browse/SUREFIRE-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463517#comment-17463517 ] Peter Firmstone commented on SUREFIRE-1916: --- The comment: "Unlikely unless someone is using their own implementation of PrintStream..." And the use of : java.lang.Thread.State: BLOCKED (on object monitor) at org.fusesource.jansi.FilterPrintStream.println(FilterPrintStream.java:231) The fix would be to thread confine logging to a single threaded executor and submit log messages to a queue. I did something similar here (feel free to copy it if you want, I am the author and have signed an Apache contributor agreement): https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/logging/LogDispatch.java > thread blocked freezing progress > > > Key: SUREFIRE-1916 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1916 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.22.2 > Environment: java -version > openjdk version "1.8.0_292" > OpenJDK Runtime Environment (Zulu 8.54.0.21-CA-win64) (build 1.8.0_292-b10) > OpenJDK 64-Bit Server VM (Zulu 8.54.0.21-CA-win64) (build 25.292-b10, mixed > mode) >Reporter: Peter Firmstone >Priority: Minor > > Thread live lock during reporting. I'll update to a later release, this is > very uncommon it's never happened before, just thought I'd report it here. > > 2021-06-03 12:16:36 > Full thread dump OpenJDK 64-Bit Server VM (25.292-b10 mixed mode): > "ThreadedStreamConsumer" #40 daemon prio=5 os_prio=0 tid=0x3cd46800 > nid=0x56b8 runnable [0x4118e000] > java.lang.Thread.State: RUNNABLE > at java.io.FileOutputStream.writeBytes(Native Method) > at java.io.FileOutputStream.write(FileOutputStream.java:326) > at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) > - locked <0x0003f2a966e0> (a java.io.BufferedOutputStream) > at java.io.PrintStream.write(PrintStream.java:482) > - locked <0x0003f2a966c0> (a java.io.PrintStream) > at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) > at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) > at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104) > - locked <0x0003f2a96808> (a java.io.OutputStreamWriter) > at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185) > at java.io.PrintStream.write(PrintStream.java:527) > - locked <0x0003f2a966c0> (a java.io.PrintStream) > at java.io.PrintStream.print(PrintStream.java:583) > at org.fusesource.jansi.FilterPrintStream.write(FilterPrintStream.java:99) > at org.fusesource.jansi.FilterPrintStream.write(FilterPrintStream.java:107) > at org.fusesource.jansi.FilterPrintStream.print(FilterPrintStream.java:156) > at org.fusesource.jansi.FilterPrintStream.println(FilterPrintStream.java:231) > - locked <0x0003f2a70188> (a org.fusesource.jansi.WindowsAnsiPrintStream) > at org.slf4j.impl.SimpleLogger.write(SimpleLogger.java:318) > at org.slf4j.impl.SimpleLogger.log(SimpleLogger.java:295) > at org.slf4j.impl.SimpleLogger.info(SimpleLogger.java:480) > at org.apache.maven.cli.logging.Slf4jLogger.info(Slf4jLogger.java:59) > at > org.apache.maven.plugin.surefire.log.PluginConsoleLogger.info(PluginConsoleLogger.java:77) > at > org.apache.maven.plugin.surefire.report.ConsoleReporter.println(ConsoleReporter.java:96) > at > org.apache.maven.plugin.surefire.report.ConsoleReporter.testSetCompleted(ConsoleReporter.java:74) > at > org.apache.maven.plugin.surefire.report.TestSetRunListener.testSetCompleted(TestSetRunListener.java:183) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.processLine(ForkClient.java:227) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:177) > at > org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:88) > at java.lang.Thread.run(Thread.java:748) > Locked ownable synchronizers: > - None > "ping-timer-10s" #39 daemon prio=5 os_prio=0 tid=0x3cd49800 > nid=0x5c54 waiting on condition [0x40e8f000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00067ff54578> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2044) > at >
[GitHub] [maven-surefire] slawekjaranowski commented on pull request #407: [SUREFIRE-1967] Fix parallel test ordering to prevent high resource consumption
slawekjaranowski commented on pull request #407: URL: https://github.com/apache/maven-surefire/pull/407#issuecomment-999142602 simply send email for given address and follow on response. -- 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-surefire] findepi commented on pull request #407: [SUREFIRE-1967] Fix parallel test ordering to prevent high resource consumption
findepi commented on pull request #407: URL: https://github.com/apache/maven-surefire/pull/407#issuecomment-999114654 @slawekjaranowski do you want me to sign up to Maven Developer List (`dev-subscr...@maven.apache.org`)? -- 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-doxia-sitetools] abelsromero opened a new pull request #19: [DOXIA-614] Pass input file name as reference to parser
abelsromero opened a new pull request #19: URL: https://github.com/apache/maven-doxia-sitetools/pull/19 Second part of https://issues.apache.org/jira/browse/DOXIA-614 (first: https://github.com/apache/maven-doxia/pull/35). The first change allowed DoxiaParsers to receive the "reference" to the source alongside the Reader, but we still need to pass the value fo the reference, otherwise it's alwasy null. -- 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-surefire] CMoH commented on a change in pull request #387: [SUREFIRE-1939] Fix NPE in SystemUtils.toJdkHomeFromJvmExec if java home has 2 components
CMoH commented on a change in pull request #387:
URL: https://github.com/apache/maven-surefire/pull/387#discussion_r77382
##
File path:
surefire-booter/src/test/java/org/apache/maven/surefire/booter/SystemUtilsTest.java
##
@@ -98,6 +98,15 @@ public void incorrectJdkPath()
assertThat( SystemUtils.isJava9AtLeast(
incorrect.getAbsolutePath() ) ).isFalse();
}
+@Test
+public void incorrectJdkPathShouldNotNPE()
Review comment:
Well, the reason I submitted this is because unit tests fail, due to
this: on my machine JAVA_HOME is `/opt/openjdk-bin-11/`. Unit test
`incorrectJdkPath()` works as follows:
```
@Test
public void incorrectJdkPath()
{
File jre = new File( System.getProperty( "java.home" ) );
File jdk = jre.getParentFile();
File incorrect = jdk.getParentFile();
assertThat( SystemUtils.isJava9AtLeast(
incorrect.getAbsolutePath() ) ).isFalse();
}
```
This leads to `incorrect=/`, which reaches `toJdkHomeFromJvmExec("/")`,
which calls again `getParent("/")`, which yields null, and next `getName()` is
called on this null. It is clear from the implementation of
`toJdkHomeFromJvmExec()` that returning null is fine when this jvmExec is not
found. I believe this is the case here.
Also, the test is about incorrect JDK paths, and such a path is an incorrect
JDK path. However, one incorrect case crashes with a non-informative NPE. I
would say a "cannot find jvm executable" error on the return-null path would be
more helpful for users that misconfigured their systems.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (DOXIASITETOOLS-227) Throwing "new ParseException(message)" shows message with "line [-1]"
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463445#comment-17463445 ] Michael Osipov commented on DOXIASITETOOLS-227: --- You are right, I have corrected the fix version. Can you verify? > Throwing "new ParseException(message)" shows message with "line [-1]" > - > > Key: DOXIASITETOOLS-227 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-227 > Project: Maven Doxia Sitetools > Issue Type: Bug > Components: Site renderer >Affects Versions: 1.9.1 >Reporter: Abel Salgado Romero >Assignee: Michael Osipov >Priority: Minor > Labels: intern > Fix For: 1.10 > > > When throwing a 'org.apache.maven.doxia.parser.ParseException' from a Doxia > module indicating only a message or source exception a message pointing to > line -1 is show in console. > Exemple: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.7.1:site (default-cli) on > project asciidoc-maven-site-example: Error parsing > '/home/asalgadr/github/asciidoctor-maven-examples/asciidoc-maven-site-example/src/site/asciidoc/article.adoc': > line [-1] Found 1 issue(s) of severity DEBUG or higher during rendering -> > [Help 1] > > I would expect that in case the line is not initialized, no reference to it > is shown in the console. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (DOXIASITETOOLS-227) Throwing "new ParseException(message)" shows message with "line [-1]"
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated DOXIASITETOOLS-227: -- Fix Version/s: 1.10 (was: 1.9.2) > Throwing "new ParseException(message)" shows message with "line [-1]" > - > > Key: DOXIASITETOOLS-227 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-227 > Project: Maven Doxia Sitetools > Issue Type: Bug > Components: Site renderer >Affects Versions: 1.9.1 >Reporter: Abel Salgado Romero >Assignee: Michael Osipov >Priority: Minor > Labels: intern > Fix For: 1.10 > > > When throwing a 'org.apache.maven.doxia.parser.ParseException' from a Doxia > module indicating only a message or source exception a message pointing to > line -1 is show in console. > Exemple: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.7.1:site (default-cli) on > project asciidoc-maven-site-example: Error parsing > '/home/asalgadr/github/asciidoctor-maven-examples/asciidoc-maven-site-example/src/site/asciidoc/article.adoc': > line [-1] Found 1 issue(s) of severity DEBUG or higher during rendering -> > [Help 1] > > I would expect that in case the line is not initialized, no reference to it > is shown in the console. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (DOXIASITETOOLS-227) Throwing "new ParseException(message)" shows message with "line [-1]"
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463433#comment-17463433 ] Abel Salgado Romero commented on DOXIASITETOOLS-227: Hi, I was checking the issue, but I am confused. Forcing `doxia-site-renderer` version in the `maven-site-plugin`it seems the fix is not in v1.9.2 as stated in this issue, but 1.10. Also, most recent `maven-site-plugin` (v3.9.1) still uses `doxia-site-renderer` v1.9.2. ¿What should be the recommended approach to use newer versions? > Throwing "new ParseException(message)" shows message with "line [-1]" > - > > Key: DOXIASITETOOLS-227 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-227 > Project: Maven Doxia Sitetools > Issue Type: Bug > Components: Site renderer >Affects Versions: 1.9.1 >Reporter: Abel Salgado Romero >Assignee: Michael Osipov >Priority: Minor > Labels: intern > Fix For: 1.9.2 > > > When throwing a 'org.apache.maven.doxia.parser.ParseException' from a Doxia > module indicating only a message or source exception a message pointing to > line -1 is show in console. > Exemple: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.7.1:site (default-cli) on > project asciidoc-maven-site-example: Error parsing > '/home/asalgadr/github/asciidoctor-maven-examples/asciidoc-maven-site-example/src/site/asciidoc/article.adoc': > line [-1] Found 1 issue(s) of severity DEBUG or higher during rendering -> > [Help 1] > > I would expect that in case the line is not initialized, no reference to it > is shown in the console. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-6795) define a replacement for ReasonPhrase to display details about transfert failures
[ https://issues.apache.org/jira/browse/MNG-6795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463390#comment-17463390 ] Michael Osipov commented on MNG-6795: - One possible way to wrap those messages is to use https://datatracker.ietf.org/doc/html/rfc7807 > define a replacement for ReasonPhrase to display details about transfert > failures > - > > Key: MNG-6795 > URL: https://issues.apache.org/jira/browse/MNG-6795 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories >Affects Versions: 3.3.9, 3.6.3 >Reporter: Herve Boutemy >Priority: Major > Fix For: 4.0.x-candidate > > > as documented in WAGON-541 > [372aa52c80c2f7b458c095d837e15ebeafbdf0b7|https://gitbox.apache.org/repos/asf?p=maven-wagon.git=commit=372aa52c80c2f7b458c095d837e15ebeafbdf0b7], > ReasonPhrase has been removed from HTTP/2 and deprecated (optional) in > HTTP/1.1 for more than five years. It is useful to give detailed error > messages on artifact transfert errors with a repository manager. > A replacement has to be found -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (MWRAPPER-13) Unclear how to use maven-wrapper-plugin
[
https://issues.apache.org/jira/browse/MWRAPPER-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MWRAPPER-13.
-
Resolution: Fixed
> Unclear how to use maven-wrapper-plugin
> ---
>
> Key: MWRAPPER-13
> URL: https://issues.apache.org/jira/browse/MWRAPPER-13
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Plugin
>Affects Versions: 3.0.2
>Reporter: Austin Doupnik
>Priority: Major
>
> I have heavily used the takari plugin in the past and am comparing to that.
> The takari plugin documentation is very clear and easy to follow, simply run
> {code:bash}
> mvn -N io.takari:maven:0.7.7:wrapper
> {code}
> I am attempting to follow what is documented
> [here|http://maven.apache.org/plugins/maven-wrapper-plugin/usage.html], but
> running into a number of problems.
> h2. Setup
> {code:bash}
> $ ~/Applications/apache-maven-3.8.1/bin/mvn archetype:generate
> -DartifactId=example -DgroupId=example -B
>
> $ cd example
> {code}
> h2. Following the documentation
> {code:bash}
> $ ~/Applications/apache-maven-3.8.1/bin/mvn wrapper
>
> [INFO] Scanning for projects...
> [INFO]
> [INFO] --< example:example
> >---
> [INFO] Building example 1.0-SNAPSHOT
> [INFO] [ jar
> ]-
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.093 s
> [INFO] Finished at: 2021-05-02T13:52:38-07:00
> [INFO]
>
> [ERROR] Unknown lifecycle phase "wrapper". You must specify a valid lifecycle
> phase or a goal in the format : or
> :[:]:. Available
> lifecycle phases are: validate, initialize, generate-sources,
> process-sources, generate-resources, process-resources, compile,
> process-classes, generate-test-sources, process-test-sources,
> generate-test-resources, process-test-resources, test-compile,
> process-test-classes, test, prepare-package, package, pre-integration-test,
> integration-test, post-integration-test, verify, install, deploy, pre-clean,
> clean, post-clean, pre-site, site, post-site, site-deploy. -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/LifecyclePhaseNotFoundException
> {code}
> h2. Trying something else
> {code:bash}
> $ ~/Applications/apache-maven-3.8.1/bin/mvn wrapper:wrapper
>
> [INFO] Scanning for projects...
> Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/2.4/maven-jar-plugin-2.4.jar
> Downloaded from central:
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/2.4/maven-jar-plugin-2.4.jar
> (34 kB at 76 kB/s)
> Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/3.1/maven-compiler-plugin-3.1.jar
> Downloaded from central:
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/3.1/maven-compiler-plugin-3.1.jar
> (43 kB at 682 kB/s)
> Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.12.4/maven-surefire-plugin-2.12.4.jar
> Downloaded from central:
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.12.4/maven-surefire-plugin-2.12.4.jar
> (30 kB at 725 kB/s)
> [INFO]
> [INFO] --< example:example
> >---
> [INFO] Building example 1.0-SNAPSHOT
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-wrapper-plugin:3.0.1:wrapper (default-cli) @ example ---
> [WARNING] The POM for org.apache.maven:apache-maven-wrapper:zip:script:3.8.1
> is missing, no dependency information available
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 1.622 s
> [INFO] Finished at: 2021-05-02T13:54:08-07:00
> [INFO]
>
> [ERROR] Failed to execute goal
>
[jira] [Closed] (MWRAPPER-43) Download of jar must be quiet by default
[
https://issues.apache.org/jira/browse/MWRAPPER-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MWRAPPER-43.
-
Fix Version/s: 3.1.1
Assignee: Herve Boutemy
Resolution: Fixed
PR merged in
https://github.com/apache/maven-wrapper/commit/b0c5a76d2b796189cf5ab8a2f19512b454382c8b
very nice improvement and explanation, thank you
> Download of jar must be quiet by default
>
>
> Key: MWRAPPER-43
> URL: https://issues.apache.org/jira/browse/MWRAPPER-43
> Project: Maven Wrapper
> Issue Type: Improvement
> Components: Maven Wrapper Scripts
>Affects Versions: 3.1.0
>Reporter: Jorge Solórzano
>Assignee: Herve Boutemy
>Priority: Normal
> Fix For: 3.1.1
>
>
> By default, the wrapper must be quiet, if the _maven-wrapper.jar_ is not
> found the scripts try to download the jar using {*}wget{*}, {*}curl{*}, or
> the {*}MavenWrapperDownloader{*}.java.
> The download process should only print the output when the +*MVNW_VERBOSE*+
> is set to true.
> Current output for *wget* when the maven-wrapper.jar is missing:
> {noformat}
> ./mvnw clean
> --2021-12-21 11:52:43--
> https://repo.maven.apache.org/maven2/org/apache/maven/wrapper/maven-wrapper/3.1.0/maven-wrapper-3.1.0.jar
> Resolving repo.maven.apache.org (repo.maven.apache.org)... 151.101.132.215
> Connecting to repo.maven.apache.org
> (repo.maven.apache.org)|151.101.132.215|:443... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 58727 (57K) [application/java-archive]
> Saving to: '/home/wrapper/api/.mvn/wrapper/maven-wrapper.jar'
> /home/jorsol/Trabajo/conf-worksp
> 100%[==>] 57,35K
> --.-KB/sin 0,007s
> 2021-12-21 11:52:44 (8,13 MB/s) -
> '/home/wrapper/api/.mvn/wrapper/maven-wrapper.jar' saved [58727/58727]
> 11:52:45.544 [INFO] Scanning for projects...
> ...
> {noformat}
> Current output for *curl* the maven-wrapper.jar is missing:
> {noformat}
> ./mvnw clean
> % Total% Received % Xferd Average Speed TimeTime Time
> Current
> Dload Upload Total SpentLeft Speed
> 100 58727 100 587270 0 1303k 0 --:--:-- --:--:-- --:--:-- 1303k
> 12:02:23.007 [INFO] Scanning for projects...
> ...
> {noformat}
> Current output for *MavenWrapperDownloader* when the maven-wrapper.jar is
> missing:
> {noformat}
> ./mvnw clean
> - Downloader started
> - Using base directory: /home/wrapper/api
> - Downloading from:
> https://repo.maven.apache.org/maven2/org/apache/maven/wrapper/maven-wrapper/3.1.0/maven-wrapper-3.1.0.jar
> - Downloading to: /home/wrapper/api/.mvn/wrapper/maven-wrapper.jar
> Done
> 11:50:21.599 [INFO] Scanning for projects...
> ...
> {noformat}
> Everything between the _./mvnw_ and the first _INFO_ is just unwanted
> verbosity.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MWRAPPER-43) Download of jar must be quiet by default
[
https://issues.apache.org/jira/browse/MWRAPPER-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463372#comment-17463372
]
ASF GitHub Bot commented on MWRAPPER-43:
hboutemy commented on pull request #12:
URL: https://github.com/apache/maven-wrapper/pull/12#issuecomment-998966338
perfect, thank you
--
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
> Download of jar must be quiet by default
>
>
> Key: MWRAPPER-43
> URL: https://issues.apache.org/jira/browse/MWRAPPER-43
> Project: Maven Wrapper
> Issue Type: Improvement
> Components: Maven Wrapper Scripts
>Affects Versions: 3.1.0
>Reporter: Jorge Solórzano
>Priority: Normal
>
> By default, the wrapper must be quiet, if the _maven-wrapper.jar_ is not
> found the scripts try to download the jar using {*}wget{*}, {*}curl{*}, or
> the {*}MavenWrapperDownloader{*}.java.
> The download process should only print the output when the +*MVNW_VERBOSE*+
> is set to true.
> Current output for *wget* when the maven-wrapper.jar is missing:
> {noformat}
> ./mvnw clean
> --2021-12-21 11:52:43--
> https://repo.maven.apache.org/maven2/org/apache/maven/wrapper/maven-wrapper/3.1.0/maven-wrapper-3.1.0.jar
> Resolving repo.maven.apache.org (repo.maven.apache.org)... 151.101.132.215
> Connecting to repo.maven.apache.org
> (repo.maven.apache.org)|151.101.132.215|:443... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 58727 (57K) [application/java-archive]
> Saving to: '/home/wrapper/api/.mvn/wrapper/maven-wrapper.jar'
> /home/jorsol/Trabajo/conf-worksp
> 100%[==>] 57,35K
> --.-KB/sin 0,007s
> 2021-12-21 11:52:44 (8,13 MB/s) -
> '/home/wrapper/api/.mvn/wrapper/maven-wrapper.jar' saved [58727/58727]
> 11:52:45.544 [INFO] Scanning for projects...
> ...
> {noformat}
> Current output for *curl* the maven-wrapper.jar is missing:
> {noformat}
> ./mvnw clean
> % Total% Received % Xferd Average Speed TimeTime Time
> Current
> Dload Upload Total SpentLeft Speed
> 100 58727 100 587270 0 1303k 0 --:--:-- --:--:-- --:--:-- 1303k
> 12:02:23.007 [INFO] Scanning for projects...
> ...
> {noformat}
> Current output for *MavenWrapperDownloader* when the maven-wrapper.jar is
> missing:
> {noformat}
> ./mvnw clean
> - Downloader started
> - Using base directory: /home/wrapper/api
> - Downloading from:
> https://repo.maven.apache.org/maven2/org/apache/maven/wrapper/maven-wrapper/3.1.0/maven-wrapper-3.1.0.jar
> - Downloading to: /home/wrapper/api/.mvn/wrapper/maven-wrapper.jar
> Done
> 11:50:21.599 [INFO] Scanning for projects...
> ...
> {noformat}
> Everything between the _./mvnw_ and the first _INFO_ is just unwanted
> verbosity.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-wrapper] hboutemy commented on pull request #12: [MWRAPPER-43] Make jar download quiet by default
hboutemy commented on pull request #12: URL: https://github.com/apache/maven-wrapper/pull/12#issuecomment-998966338 perfect, thank you -- 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] (MWRAPPER-43) Download of jar must be quiet by default
[
https://issues.apache.org/jira/browse/MWRAPPER-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463371#comment-17463371
]
ASF GitHub Bot commented on MWRAPPER-43:
hboutemy merged pull request #12:
URL: https://github.com/apache/maven-wrapper/pull/12
--
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
> Download of jar must be quiet by default
>
>
> Key: MWRAPPER-43
> URL: https://issues.apache.org/jira/browse/MWRAPPER-43
> Project: Maven Wrapper
> Issue Type: Improvement
> Components: Maven Wrapper Scripts
>Affects Versions: 3.1.0
>Reporter: Jorge Solórzano
>Priority: Normal
>
> By default, the wrapper must be quiet, if the _maven-wrapper.jar_ is not
> found the scripts try to download the jar using {*}wget{*}, {*}curl{*}, or
> the {*}MavenWrapperDownloader{*}.java.
> The download process should only print the output when the +*MVNW_VERBOSE*+
> is set to true.
> Current output for *wget* when the maven-wrapper.jar is missing:
> {noformat}
> ./mvnw clean
> --2021-12-21 11:52:43--
> https://repo.maven.apache.org/maven2/org/apache/maven/wrapper/maven-wrapper/3.1.0/maven-wrapper-3.1.0.jar
> Resolving repo.maven.apache.org (repo.maven.apache.org)... 151.101.132.215
> Connecting to repo.maven.apache.org
> (repo.maven.apache.org)|151.101.132.215|:443... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 58727 (57K) [application/java-archive]
> Saving to: '/home/wrapper/api/.mvn/wrapper/maven-wrapper.jar'
> /home/jorsol/Trabajo/conf-worksp
> 100%[==>] 57,35K
> --.-KB/sin 0,007s
> 2021-12-21 11:52:44 (8,13 MB/s) -
> '/home/wrapper/api/.mvn/wrapper/maven-wrapper.jar' saved [58727/58727]
> 11:52:45.544 [INFO] Scanning for projects...
> ...
> {noformat}
> Current output for *curl* the maven-wrapper.jar is missing:
> {noformat}
> ./mvnw clean
> % Total% Received % Xferd Average Speed TimeTime Time
> Current
> Dload Upload Total SpentLeft Speed
> 100 58727 100 587270 0 1303k 0 --:--:-- --:--:-- --:--:-- 1303k
> 12:02:23.007 [INFO] Scanning for projects...
> ...
> {noformat}
> Current output for *MavenWrapperDownloader* when the maven-wrapper.jar is
> missing:
> {noformat}
> ./mvnw clean
> - Downloader started
> - Using base directory: /home/wrapper/api
> - Downloading from:
> https://repo.maven.apache.org/maven2/org/apache/maven/wrapper/maven-wrapper/3.1.0/maven-wrapper-3.1.0.jar
> - Downloading to: /home/wrapper/api/.mvn/wrapper/maven-wrapper.jar
> Done
> 11:50:21.599 [INFO] Scanning for projects...
> ...
> {noformat}
> Everything between the _./mvnw_ and the first _INFO_ is just unwanted
> verbosity.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-wrapper] hboutemy merged pull request #12: [MWRAPPER-43] Make jar download quiet by default
hboutemy merged pull request #12: URL: https://github.com/apache/maven-wrapper/pull/12 -- 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] (MWRAPPER-43) Download of jar must be quiet by default
[
https://issues.apache.org/jira/browse/MWRAPPER-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463370#comment-17463370
]
Herve Boutemy commented on MWRAPPER-43:
---
thank you [~jorsol]: now I perfectly see the expected improvement :)
I'll review the PR soon
> Download of jar must be quiet by default
>
>
> Key: MWRAPPER-43
> URL: https://issues.apache.org/jira/browse/MWRAPPER-43
> Project: Maven Wrapper
> Issue Type: Improvement
> Components: Maven Wrapper Scripts
>Affects Versions: 3.1.0
>Reporter: Jorge Solórzano
>Priority: Normal
>
> By default, the wrapper must be quiet, if the _maven-wrapper.jar_ is not
> found the scripts try to download the jar using {*}wget{*}, {*}curl{*}, or
> the {*}MavenWrapperDownloader{*}.java.
> The download process should only print the output when the +*MVNW_VERBOSE*+
> is set to true.
> Current output for *wget* when the maven-wrapper.jar is missing:
> {noformat}
> ./mvnw clean
> --2021-12-21 11:52:43--
> https://repo.maven.apache.org/maven2/org/apache/maven/wrapper/maven-wrapper/3.1.0/maven-wrapper-3.1.0.jar
> Resolving repo.maven.apache.org (repo.maven.apache.org)... 151.101.132.215
> Connecting to repo.maven.apache.org
> (repo.maven.apache.org)|151.101.132.215|:443... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 58727 (57K) [application/java-archive]
> Saving to: '/home/wrapper/api/.mvn/wrapper/maven-wrapper.jar'
> /home/jorsol/Trabajo/conf-worksp
> 100%[==>] 57,35K
> --.-KB/sin 0,007s
> 2021-12-21 11:52:44 (8,13 MB/s) -
> '/home/wrapper/api/.mvn/wrapper/maven-wrapper.jar' saved [58727/58727]
> 11:52:45.544 [INFO] Scanning for projects...
> ...
> {noformat}
> Current output for *curl* the maven-wrapper.jar is missing:
> {noformat}
> ./mvnw clean
> % Total% Received % Xferd Average Speed TimeTime Time
> Current
> Dload Upload Total SpentLeft Speed
> 100 58727 100 587270 0 1303k 0 --:--:-- --:--:-- --:--:-- 1303k
> 12:02:23.007 [INFO] Scanning for projects...
> ...
> {noformat}
> Current output for *MavenWrapperDownloader* when the maven-wrapper.jar is
> missing:
> {noformat}
> ./mvnw clean
> - Downloader started
> - Using base directory: /home/wrapper/api
> - Downloading from:
> https://repo.maven.apache.org/maven2/org/apache/maven/wrapper/maven-wrapper/3.1.0/maven-wrapper-3.1.0.jar
> - Downloading to: /home/wrapper/api/.mvn/wrapper/maven-wrapper.jar
> Done
> 11:50:21.599 [INFO] Scanning for projects...
> ...
> {noformat}
> Everything between the _./mvnw_ and the first _INFO_ is just unwanted
> verbosity.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] slawekjaranowski closed pull request #402: Bump htmlunit from 2.33 to 2.55.0
slawekjaranowski closed pull request #402: URL: https://github.com/apache/maven-surefire/pull/402 -- 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-surefire] dependabot[bot] commented on pull request #404: Bump hamcrest-library from 1.3 to 2.2
dependabot[bot] commented on pull request #404: URL: https://github.com/apache/maven-surefire/pull/404#issuecomment-998962723 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on 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-surefire] dependabot[bot] commented on pull request #402: Bump htmlunit from 2.33 to 2.55.0
dependabot[bot] commented on pull request #402: URL: https://github.com/apache/maven-surefire/pull/402#issuecomment-998962847 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on 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-surefire] slawekjaranowski closed pull request #404: Bump hamcrest-library from 1.3 to 2.2
slawekjaranowski closed pull request #404: URL: https://github.com/apache/maven-surefire/pull/404 -- 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-surefire] dependabot[bot] commented on pull request #411: Bump animal-sniffer-maven-plugin from 1.17 to 1.20
dependabot[bot] commented on pull request #411: URL: https://github.com/apache/maven-surefire/pull/411#issuecomment-998962059 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on 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-surefire] slawekjaranowski closed pull request #405: Bump javassist from 3.22.0-GA to 3.28.0-GA
slawekjaranowski closed pull request #405: URL: https://github.com/apache/maven-surefire/pull/405 -- 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-surefire] dependabot[bot] commented on pull request #405: Bump javassist from 3.22.0-GA to 3.28.0-GA
dependabot[bot] commented on pull request #405: URL: https://github.com/apache/maven-surefire/pull/405#issuecomment-998962482 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on 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-surefire] dependabot[bot] commented on pull request #406: Bump junit-jupiter-engine from 5.3.2 to 5.8.2
dependabot[bot] commented on pull request #406: URL: https://github.com/apache/maven-surefire/pull/406#issuecomment-998962183 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on 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-surefire] slawekjaranowski closed pull request #406: Bump junit-jupiter-engine from 5.3.2 to 5.8.2
slawekjaranowski closed pull request #406: URL: https://github.com/apache/maven-surefire/pull/406 -- 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-surefire] slawekjaranowski closed pull request #411: Bump animal-sniffer-maven-plugin from 1.17 to 1.20
slawekjaranowski closed pull request #411: URL: https://github.com/apache/maven-surefire/pull/411 -- 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-surefire] slawekjaranowski closed pull request #163: Surefire-report
slawekjaranowski closed pull request #163: URL: https://github.com/apache/maven-surefire/pull/163 -- 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-surefire] slawekjaranowski closed pull request #102: Option to rerun failures at the end of test execution
slawekjaranowski closed pull request #102: URL: https://github.com/apache/maven-surefire/pull/102 -- 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-surefire] slawekjaranowski commented on pull request #102: Option to rerun failures at the end of test execution
slawekjaranowski commented on pull request #102: URL: https://github.com/apache/maven-surefire/pull/102#issuecomment-998959629 I close this PR, a lot of time has passed and many things could have changed. If you still interested please create jira issue first or find one which can be connected. Many thanks for collaborations. -- 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] (MWRAPPER-42) maven-wrapper fails to self-update maven-wrapper.jar
[ https://issues.apache.org/jira/browse/MWRAPPER-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463364#comment-17463364 ] Jeremy Norris commented on MWRAPPER-42: --- Ok, I'll start talking to my company about getting a CLA executed. It may take a bit since we're coming up on the holidays. > maven-wrapper fails to self-update maven-wrapper.jar > > > Key: MWRAPPER-42 > URL: https://issues.apache.org/jira/browse/MWRAPPER-42 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: Jeremy Norris >Priority: Major > Fix For: 3.1.1 > > > In cases where users do not check-in the maven-wrapper.jar into their > repositories, after executing `mvn wrapper:wrapper -Dtype=script` to update, > the newly updated `mvnw` script will continue to use an older version of > `.mvn/wrapper/maven-wrapper.jar` that was previously downloaded. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MWRAPPER-42) maven-wrapper fails to self-update maven-wrapper.jar
[ https://issues.apache.org/jira/browse/MWRAPPER-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463362#comment-17463362 ] Herve Boutemy commented on MWRAPPER-42: --- for small contributions, there is no need for CLA but you're right that it's better to anticipate big contributions :) > maven-wrapper fails to self-update maven-wrapper.jar > > > Key: MWRAPPER-42 > URL: https://issues.apache.org/jira/browse/MWRAPPER-42 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: Jeremy Norris >Priority: Major > Fix For: 3.1.1 > > > In cases where users do not check-in the maven-wrapper.jar into their > repositories, after executing `mvn wrapper:wrapper -Dtype=script` to update, > the newly updated `mvnw` script will continue to use an older version of > `.mvn/wrapper/maven-wrapper.jar` that was previously downloaded. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-surefire] slawekjaranowski closed pull request #96: Adding individual rerun times to XML reports
slawekjaranowski closed pull request #96: URL: https://github.com/apache/maven-surefire/pull/96 -- 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-surefire] slawekjaranowski commented on pull request #96: Adding individual rerun times to XML reports
slawekjaranowski commented on pull request #96: URL: https://github.com/apache/maven-surefire/pull/96#issuecomment-998958189 I close this PR, a lot of time has passed and many things could have changed. If you still interested please create jira issue first. Many thanks for collaborations. -- 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] (MJAR-275) outputTimestamp not applied to module-info; breaks reproducible builds
[
https://issues.apache.org/jira/browse/MJAR-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17462180#comment-17462180
]
Michael Osipov edited comment on MJAR-275 at 12/21/21, 5:15 PM:
I have dropped an email to the OSS liaison of Oracle for a backport. The issue
seems to be addressed in Java 18.
was (Author: michael-o):
I have dropped an email to the OSS liaison of Oracle for an backport. The issue
seems to be addressed in Java 18.
> outputTimestamp not applied to module-info; breaks reproducible builds
> --
>
> Key: MJAR-275
> URL: https://issues.apache.org/jira/browse/MJAR-275
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
> Environment: Mac OS X 10.14.6
> JDK 15 (build 15+36)
> JDK 11 (build 11.0.8+10)
>Reporter: Anand Beh
>Priority: Minor
> Attachments: MCOMPILER-439.zip, Screenshot 2020-10-25 at 2.35.59
> PM.png
>
>
> Setting {{project.build.outputTimestamp}} to a fixed value allows creating
> reproducible builds per this guide:
> [https://maven.apache.org/guides/mini/guide-reproducible-builds.html
> |https://maven.apache.org/guides/mini/guide-reproducible-builds.html]However,
> if one adds a module-info file to the project, reproducible builds break.
> This is caused by module-info.class using the latest timestamp and not
> {{project.build.outputTimestamp}}. I was able to identify the problem using
> diffoscope: [https://diffoscope.org/.|https://diffoscope.org/] With it I
> determined the timestamp across 2 builds was constant for all but the
> module-info.class:
>
> {code:java}
> -rw 2.0 fat 862 bl defN 20-Oct-17 00:40
> space/arim/libertybans/api/select/SelectionOrder.class
> │ -rw 2.0 fat 1113 bl defN 20-Oct-17 00:40
> space/arim/libertybans/api/select/SelectionOrderBuilder.class
> │ -rw 2.0 fat 2285 bl defN 20-Oct-17 00:40
> META-INF/maven/space.arim.libertybans/bans-api/pom.xml
> │ -rw 2.0 fat 74 bl defN 20-Oct-17 00:40
> META-INF/maven/space.arim.libertybans/bans-api/pom.properties
> │ --rw 2.0 fat 557 bl defN 20-Oct-25 12:39 module-info.class
> │ +-rw 2.0 fat 557 bl defN 20-Oct-25 12:41 module-info.class
> {code}
>
> Note the + and - which are diffoscope's way of indicating the difference
> between the .jar files. Here the {{project.build.outputTimestamp}} is on 17
> October. As shown, module-info has a "rebellious" timestamp.
>
> *EDIT:*
> Example project to reproduce the bug:
> [https://github.com/A248/MJAR-275|https://github.com/A248/MCOMPILER-439]
> (Renamed from [https://github.com/A248/MCOMPILER-439])
> Source code is also provided as an attachment below
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] slawekjaranowski commented on a change in pull request #400: [SUREFIRE-1964] Support for method filtering on excludesFile and includesFile
slawekjaranowski commented on a change in pull request #400:
URL: https://github.com/apache/maven-surefire/pull/400#discussion_r773294587
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -1839,14 +1842,38 @@ private PluginFailureReason getEffectiveFailIfNoTests()
{
if ( isSpecificTestSpecified() )
{
-return getFailIfNoSpecifiedTests() ? COULD_NOT_RUN_SPECIFIED_TESTS
: NONE;
+if ( getFailIfNoSpecifiedTests()
+&& isTestToIncludeExcludeNoSpecified() )
+{
+return COULD_NOT_RUN_SPECIFIED_TESTS;
+}
+else
+{
+return NONE;
+}
}
else
{
return getFailIfNoTests() ? COULD_NOT_RUN_DEFAULT_TESTS : NONE;
}
}
+private boolean isTestToIncludeExcludeNoSpecified()
+{
+return getTestToIncludeExclude().isEmpty();
+}
+
+private void setTestToIncludeExclude( String test )
+{
+this.testToIncludeExclude = test;
+setTest( test );
+}
Review comment:
mixed responsibility ..
when I see a call some setter method I expect that one property will be set
...
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2282,32 +2336,113 @@ private void maybeAppendList( List base,
List list )
return filterNulls( includes );
}
-private void checkMethodFilterInIncludesExcludes( Iterable
patterns )
-throws MojoFailureException
+private List getMethodFilterInIncludesExcludes( Iterable
patterns )
{
+List methodFilterInIncludesExcludes = new LinkedList<>();
if ( patterns != null )
{
for ( String pattern : patterns )
{
if ( pattern != null && pattern.contains( "#" ) )
{
-throw new MojoFailureException( "Method filter prohibited
in "
-+
"includes|excludes|includesFile|excludesFile parameter: "
-+ pattern );
+methodFilterInIncludesExcludes.add( pattern );
}
}
}
+return methodFilterInIncludesExcludes;
}
private TestListResolver getIncludedAndExcludedTests()
throws MojoFailureException
{
if ( includedExcludedTests == null )
{
-includedExcludedTests = new TestListResolver( getIncludeList(),
getExcludeList() );
+StringBuilder sb = new StringBuilder();
+List includeList = getIncludeList();
+for ( String include: includeList )
+{
+sb.append( "," ).append( include );
+}
+IncludeExcludeList excludeList = getExcludeList();
+List excludedTestMethods = excludeList.getTestMethods();
+if ( !excludedTestMethods.isEmpty() )
+{
+includeList.clear();
Review comment:
`includeList` is return value from `getIncludeList` should be immutable
...
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2271,7 +2324,8 @@ private void maybeAppendList( List base,
List list )
maybeAppendList( includes, getIncludes() );
}
-checkMethodFilterInIncludesExcludes( includes );
+List methodFilterInIncludes =
getMethodFilterInIncludesExcludes( includes );
+addAll( includes, methodFilterInIncludes.toArray( new String[0] )
);
Review comment:
`includes` can be reference to anything - should be immutable
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2282,32 +2336,113 @@ private void maybeAppendList( List base,
List list )
return filterNulls( includes );
}
-private void checkMethodFilterInIncludesExcludes( Iterable
patterns )
-throws MojoFailureException
+private List getMethodFilterInIncludesExcludes( Iterable
patterns )
{
+List methodFilterInIncludesExcludes = new LinkedList<>();
if ( patterns != null )
{
for ( String pattern : patterns )
{
if ( pattern != null && pattern.contains( "#" ) )
{
-throw new MojoFailureException( "Method filter prohibited
in "
-+
"includes|excludes|includesFile|excludesFile parameter: "
-+ pattern );
+methodFilterInIncludesExcludes.add( pattern );
}
[jira] [Commented] (MJAR-275) outputTimestamp not applied to module-info; breaks reproducible builds
[
https://issues.apache.org/jira/browse/MJAR-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463356#comment-17463356
]
Jorge Solórzano commented on MJAR-275:
--
It's nice that this issue is fixed in Java 18, crossing my fingers for a
backport to at least Java 17.
> outputTimestamp not applied to module-info; breaks reproducible builds
> --
>
> Key: MJAR-275
> URL: https://issues.apache.org/jira/browse/MJAR-275
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
> Environment: Mac OS X 10.14.6
> JDK 15 (build 15+36)
> JDK 11 (build 11.0.8+10)
>Reporter: Anand Beh
>Priority: Minor
> Attachments: MCOMPILER-439.zip, Screenshot 2020-10-25 at 2.35.59
> PM.png
>
>
> Setting {{project.build.outputTimestamp}} to a fixed value allows creating
> reproducible builds per this guide:
> [https://maven.apache.org/guides/mini/guide-reproducible-builds.html
> |https://maven.apache.org/guides/mini/guide-reproducible-builds.html]However,
> if one adds a module-info file to the project, reproducible builds break.
> This is caused by module-info.class using the latest timestamp and not
> {{project.build.outputTimestamp}}. I was able to identify the problem using
> diffoscope: [https://diffoscope.org/.|https://diffoscope.org/] With it I
> determined the timestamp across 2 builds was constant for all but the
> module-info.class:
>
> {code:java}
> -rw 2.0 fat 862 bl defN 20-Oct-17 00:40
> space/arim/libertybans/api/select/SelectionOrder.class
> │ -rw 2.0 fat 1113 bl defN 20-Oct-17 00:40
> space/arim/libertybans/api/select/SelectionOrderBuilder.class
> │ -rw 2.0 fat 2285 bl defN 20-Oct-17 00:40
> META-INF/maven/space.arim.libertybans/bans-api/pom.xml
> │ -rw 2.0 fat 74 bl defN 20-Oct-17 00:40
> META-INF/maven/space.arim.libertybans/bans-api/pom.properties
> │ --rw 2.0 fat 557 bl defN 20-Oct-25 12:39 module-info.class
> │ +-rw 2.0 fat 557 bl defN 20-Oct-25 12:41 module-info.class
> {code}
>
> Note the + and - which are diffoscope's way of indicating the difference
> between the .jar files. Here the {{project.build.outputTimestamp}} is on 17
> October. As shown, module-info has a "rebellious" timestamp.
>
> *EDIT:*
> Example project to reproduce the bug:
> [https://github.com/A248/MJAR-275|https://github.com/A248/MCOMPILER-439]
> (Renamed from [https://github.com/A248/MCOMPILER-439])
> Source code is also provided as an attachment below
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] slawekjaranowski commented on pull request #399: [SUREFIRE-1963] Detecting multiple test-frameworks
slawekjaranowski commented on pull request #399: URL: https://github.com/apache/maven-surefire/pull/399#issuecomment-998923351 Make providers to be greedy it is not easy, we have many corrner cases. The most of projects (99%) not need support for multiple providers and one provider it is ok, or must be configured manually if want to use multiple framework. We shouldn't complicate code for detecting and executing provaiders only for a few cases - it is complicated enough now. This change don't change current behavior, with empty `multipleFrameworks` nothing change but add possibility to detecting wrong test configuration. -- 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] [Assigned] (SUREFIRE-1398) TestNG test fails when both JUnitCore provider and TestNG provider are on classpath
[
https://issues.apache.org/jira/browse/SUREFIRE-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski reassigned SUREFIRE-1398:
-
Assignee: Slawomir Jaranowski
> TestNG test fails when both JUnitCore provider and TestNG provider are on
> classpath
> ---
>
> Key: SUREFIRE-1398
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1398
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, TestNG support
>Affects Versions: 2.20
>Reporter: Matous Jobanek
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: Backlog
>
>
> When both JUnitCore and TestNG providers are on classpath:
> {code:xml}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.20
>
>
> org.apache.maven.surefire
> surefire-junit47
> 2.20
>
>
> org.apache.maven.surefire
> surefire-testng
> 2.20
>
>
>
> {code}
> then the TestNG execution fails with a message:
> {noformat}
> Configuring TestNG with: TestNG60Configurator
> Cannot use a threadCount parameter less than 1; 1 > 0
> Usage: [options] The XML suite files to run
> Options:
> -configfailurepolicy
>Configuration failure policy (skip or continue)
> -d
>Output directory
> -dataproviderthreadcount
>Number of threads to use when running data providers
> -excludegroups
>Comma-separated list of group names to exclude
> -groups
>Comma-separated list of group names to be run
> -junit
>JUnit mode
>Default: false
> -listener
>List of .class files or list of class names implementing ITestListener
> or
>ISuiteListener
> -methods
>Comma separated of test methods
>Default: []
> -methodselectors
>List of .class files or list of class names implementing
> IMethodSelector
> -mixed
>Mixed mode - autodetect the type of current test and run it with
>appropriate runner
>Default: false
> -objectfactory
>List of .class files or list of class names implementing
>ITestRunnerFactory
> -parallel
>Parallel mode (methods, tests or classes)
>Possible Values: [tests, methods, classes, instances, none, true,
> false]
> -port
>The port
> -reporter
>Extended configuration for custom report listener
> -suitename
>Default name of test suite, if not specified in suite definition file
> or
>source code
> -suitethreadpoolsize
>Size of the thread pool to use to run suites
>Default: 1
> -testclass
>The list of test classes
> -testjar
>A jar file containing the tests
> -testname
>Default name of test, if not specified in suitedefinition file or
> source
>code
> -testnames
>The list of test names to run
> -testrunfactory, -testRunFactory
>The factory used to create tests
> -threadcount
>Number of threads to use when running tests in parallel
> -usedefaultlisteners
>Whether to use the default listeners
>Default: true
> -log, -verbose
>Level of verbosity
> -xmlpathinjar
>The full path to the xml file inside the jar file (only valid if
> -testjar
>was specified)
>Default: testng.xml
> {noformat}
> The same behavior occurs when instead of these two providers I use my own
> dynamic provider and delegate the execution to the TestNG provider.
> The cause of the behavior is a combination of the method
> [convertJunitCoreParameters()|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1289]
> and the TestNG provider.
> The method is called for
> [JunitCoreProvider|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2696]
> and sets the thread count to the current value (no matter if it is set or
> not). In case that it is not set, then the value is 0, which causes the
> before mentioned failure when {{TestNGProvider}} is being executed.
> The same in case of
> [DynamicProvider|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2745]
> In the description of the parameter
>
[jira] [Updated] (SUREFIRE-1398) TestNG test fails when both JUnitCore provider and TestNG provider are on classpath
[
https://issues.apache.org/jira/browse/SUREFIRE-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated SUREFIRE-1398:
--
Fix Version/s: 3.0.0-M6
(was: Backlog)
> TestNG test fails when both JUnitCore provider and TestNG provider are on
> classpath
> ---
>
> Key: SUREFIRE-1398
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1398
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, TestNG support
>Affects Versions: 2.20
>Reporter: Matous Jobanek
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> When both JUnitCore and TestNG providers are on classpath:
> {code:xml}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.20
>
>
> org.apache.maven.surefire
> surefire-junit47
> 2.20
>
>
> org.apache.maven.surefire
> surefire-testng
> 2.20
>
>
>
> {code}
> then the TestNG execution fails with a message:
> {noformat}
> Configuring TestNG with: TestNG60Configurator
> Cannot use a threadCount parameter less than 1; 1 > 0
> Usage: [options] The XML suite files to run
> Options:
> -configfailurepolicy
>Configuration failure policy (skip or continue)
> -d
>Output directory
> -dataproviderthreadcount
>Number of threads to use when running data providers
> -excludegroups
>Comma-separated list of group names to exclude
> -groups
>Comma-separated list of group names to be run
> -junit
>JUnit mode
>Default: false
> -listener
>List of .class files or list of class names implementing ITestListener
> or
>ISuiteListener
> -methods
>Comma separated of test methods
>Default: []
> -methodselectors
>List of .class files or list of class names implementing
> IMethodSelector
> -mixed
>Mixed mode - autodetect the type of current test and run it with
>appropriate runner
>Default: false
> -objectfactory
>List of .class files or list of class names implementing
>ITestRunnerFactory
> -parallel
>Parallel mode (methods, tests or classes)
>Possible Values: [tests, methods, classes, instances, none, true,
> false]
> -port
>The port
> -reporter
>Extended configuration for custom report listener
> -suitename
>Default name of test suite, if not specified in suite definition file
> or
>source code
> -suitethreadpoolsize
>Size of the thread pool to use to run suites
>Default: 1
> -testclass
>The list of test classes
> -testjar
>A jar file containing the tests
> -testname
>Default name of test, if not specified in suitedefinition file or
> source
>code
> -testnames
>The list of test names to run
> -testrunfactory, -testRunFactory
>The factory used to create tests
> -threadcount
>Number of threads to use when running tests in parallel
> -usedefaultlisteners
>Whether to use the default listeners
>Default: true
> -log, -verbose
>Level of verbosity
> -xmlpathinjar
>The full path to the xml file inside the jar file (only valid if
> -testjar
>was specified)
>Default: testng.xml
> {noformat}
> The same behavior occurs when instead of these two providers I use my own
> dynamic provider and delegate the execution to the TestNG provider.
> The cause of the behavior is a combination of the method
> [convertJunitCoreParameters()|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1289]
> and the TestNG provider.
> The method is called for
> [JunitCoreProvider|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2696]
> and sets the thread count to the current value (no matter if it is set or
> not). In case that it is not set, then the value is 0, which causes the
> before mentioned failure when {{TestNGProvider}} is being executed.
> The same in case of
> [DynamicProvider|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2745]
> In the description of the parameter
>
[GitHub] [maven-surefire] papegaaij commented on pull request #389: [SUREFIRE-1935] Upgrade to JUnit Platform 1.8, start Launcher via LauncherSession
papegaaij commented on pull request #389: URL: https://github.com/apache/maven-surefire/pull/389#issuecomment-998812535 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-surefire] slawekjaranowski commented on pull request #389: [SUREFIRE-1935] Upgrade to JUnit Platform 1.8, start Launcher via LauncherSession
slawekjaranowski commented on pull request #389: URL: https://github.com/apache/maven-surefire/pull/389#issuecomment-998781866 please rebase with current code -- 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-surefire] slawekjaranowski edited a comment on pull request #398: [SUREFIRE-1962] Unit test for ProviderInfo#isApplicable
slawekjaranowski edited a comment on pull request #398: URL: https://github.com/apache/maven-surefire/pull/398#issuecomment-998770445 ok, it is not important now ... I will work on it later now switch to draft -- 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-surefire] slawekjaranowski commented on pull request #398: [SUREFIRE-1962] Unit test for ProviderInfo#isApplicable
slawekjaranowski commented on pull request #398: URL: https://github.com/apache/maven-surefire/pull/398#issuecomment-998770445 ok, it is not important now ... I will work on it later no switch to draft -- 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-surefire] rmannibucau commented on pull request #399: [SUREFIRE-1963] Detecting multiple test-frameworks
rmannibucau commented on pull request #399: URL: https://github.com/apache/maven-surefire/pull/399#issuecomment-998763325 Think it must not be integrated but instead we should have the providers to be greedy, ie while we find tests with a provider they must be executed once (the first provider in the list supporting the test is used). No reason to fail when we know how to do. If user wants to enforce a particular engine then he must configure it but it is the design of surefire already so failling wouldn't help IMHO. -- 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-surefire] rmannibucau commented on pull request #398: [SUREFIRE-1962] Unit test for ProviderInfo#isApplicable
rmannibucau commented on pull request #398: URL: https://github.com/apache/maven-surefire/pull/398#issuecomment-998762279 @slawekjaranowski got it but don't think it has much value without a real setup (skipping the detection which is the point of these selection). That said no big opposition against such test. Can you drop fest assertions and use plain junit assertions and replace mockito by an abstract surefire mojo subclass supporting the config you want, something along: `new ProviderSurefire(/*parallel*/ false, /*groups*/ false, ...)`. Will make the tests easier to read and more reliable in time. Then consider you get my +1 even if I'm off for Xmas ;). -- 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-surefire] rmannibucau commented on a change in pull request #387: [SUREFIRE-1939] Fix NPE in SystemUtils.toJdkHomeFromJvmExec if java home has 2 components
rmannibucau commented on a change in pull request #387: URL: https://github.com/apache/maven-surefire/pull/387#discussion_r773116452 ## File path: surefire-booter/src/test/java/org/apache/maven/surefire/booter/SystemUtilsTest.java ## @@ -98,6 +98,15 @@ public void incorrectJdkPath() assertThat( SystemUtils.isJava9AtLeast( incorrect.getAbsolutePath() ) ).isFalse(); } +@Test +public void incorrectJdkPathShouldNotNPE() Review comment: is `jvmExecutable` set to `/opt/jdk` instead of `/opt/jdk/bin/java` in your case? this test is written to make `jdk=/opt` and `jre=/opt/jdk/` which I can understand you want a case with a single segment path but is not aligned on the description and only possible if the jdk is extracted at the root of the filesystem, is it your case? Also it means the jvmExecutable is not the executable so something is wrong higher in the processing and must be fixed preventing this NPE later so I would rather chase this cause instead of swallowing it. Any inputs on these points? -- 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-surefire] slawekjaranowski commented on pull request #407: [SUREFIRE-1967] Fix parallel test ordering to prevent high resource consumption
slawekjaranowski commented on pull request #407: URL: https://github.com/apache/maven-surefire/pull/407#issuecomment-998758235 @findepi - please follow dev mailing 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
[jira] [Created] (MWRAPPER-44) maven-wrapper may use outdated MavenWrapperDownloader.class
Jeremy Norris created MWRAPPER-44: - Summary: maven-wrapper may use outdated MavenWrapperDownloader.class Key: MWRAPPER-44 URL: https://issues.apache.org/jira/browse/MWRAPPER-44 Project: Maven Wrapper Issue Type: Bug Components: Maven Wrapper Scripts Affects Versions: 3.1.0 Reporter: Jeremy Norris When the mvnw script falls back to using MavenWrapperDownloader, it will use an existing copy of MavenWrapperDownloader.class that may have originated from compiling with an older version of MavenWrapperDownloader.java instead of the current release version that is checked into the repository. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MWRAPPER-42) maven-wrapper fails to self-update maven-wrapper.jar
[ https://issues.apache.org/jira/browse/MWRAPPER-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463203#comment-17463203 ] Jeremy Norris commented on MWRAPPER-42: --- Am I correct in that you would require a contributor agreement for submission of an IT? If so, is this the location of the correct agreement to execute: https://www.apache.org/licenses/contributor-agreements.html ? > maven-wrapper fails to self-update maven-wrapper.jar > > > Key: MWRAPPER-42 > URL: https://issues.apache.org/jira/browse/MWRAPPER-42 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: Jeremy Norris >Priority: Major > Fix For: 3.1.1 > > > In cases where users do not check-in the maven-wrapper.jar into their > repositories, after executing `mvn wrapper:wrapper -Dtype=script` to update, > the newly updated `mvnw` script will continue to use an older version of > `.mvn/wrapper/maven-wrapper.jar` that was previously downloaded. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MWRAPPER-43) Download of jar must be quiet by default
[
https://issues.apache.org/jira/browse/MWRAPPER-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463177#comment-17463177
]
Jorge Solórzano commented on MWRAPPER-43:
-
[~hboutemy] I have updated the description with the current output of every
command, essentially all that is between ./mvnw and the first INFO message
(from maven) is verbosity that should be hidden by default.
> Download of jar must be quiet by default
>
>
> Key: MWRAPPER-43
> URL: https://issues.apache.org/jira/browse/MWRAPPER-43
> Project: Maven Wrapper
> Issue Type: Improvement
> Components: Maven Wrapper Scripts
>Affects Versions: 3.1.0
>Reporter: Jorge Solórzano
>Priority: Normal
>
> By default, the wrapper must be quiet, if the _maven-wrapper.jar_ is not
> found the scripts try to download the jar using {*}wget{*}, {*}curl{*}, or
> the {*}MavenWrapperDownloader{*}.java.
> The download process should only print the output when the +*MVNW_VERBOSE*+
> is set to true.
> Current output for *wget* when the maven-wrapper.jar is missing:
> {noformat}
> ./mvnw clean
> --2021-12-21 11:52:43--
> https://repo.maven.apache.org/maven2/org/apache/maven/wrapper/maven-wrapper/3.1.0/maven-wrapper-3.1.0.jar
> Resolving repo.maven.apache.org (repo.maven.apache.org)... 151.101.132.215
> Connecting to repo.maven.apache.org
> (repo.maven.apache.org)|151.101.132.215|:443... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 58727 (57K) [application/java-archive]
> Saving to: '/home/wrapper/api/.mvn/wrapper/maven-wrapper.jar'
> /home/jorsol/Trabajo/conf-worksp
> 100%[==>] 57,35K
> --.-KB/sin 0,007s
> 2021-12-21 11:52:44 (8,13 MB/s) -
> '/home/wrapper/api/.mvn/wrapper/maven-wrapper.jar' saved [58727/58727]
> 11:52:45.544 [INFO] Scanning for projects...
> ...
> {noformat}
> Current output for *curl* the maven-wrapper.jar is missing:
> {noformat}
> ./mvnw clean
> % Total% Received % Xferd Average Speed TimeTime Time
> Current
> Dload Upload Total SpentLeft Speed
> 100 58727 100 587270 0 1303k 0 --:--:-- --:--:-- --:--:-- 1303k
> 12:02:23.007 [INFO] Scanning for projects...
> ...
> {noformat}
> Current output for *MavenWrapperDownloader* when the maven-wrapper.jar is
> missing:
> {noformat}
> ./mvnw clean
> - Downloader started
> - Using base directory: /home/wrapper/api
> - Downloading from:
> https://repo.maven.apache.org/maven2/org/apache/maven/wrapper/maven-wrapper/3.1.0/maven-wrapper-3.1.0.jar
> - Downloading to: /home/wrapper/api/.mvn/wrapper/maven-wrapper.jar
> Done
> 11:50:21.599 [INFO] Scanning for projects...
> ...
> {noformat}
> Everything between the _./mvnw_ and the first _INFO_ is just unwanted
> verbosity.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MWRAPPER-43) Download of jar must be quiet by default
[
https://issues.apache.org/jira/browse/MWRAPPER-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Solórzano updated MWRAPPER-43:
Description:
By default, the wrapper must be quiet, if the _maven-wrapper.jar_ is not found
the scripts try to download the jar using {*}wget{*}, {*}curl{*}, or the
{*}MavenWrapperDownloader{*}.java.
The download process should only print the output when the +*MVNW_VERBOSE*+ is
set to true.
Current output for *wget* when the maven-wrapper.jar is missing:
{noformat}
./mvnw clean
--2021-12-21 11:52:43--
https://repo.maven.apache.org/maven2/org/apache/maven/wrapper/maven-wrapper/3.1.0/maven-wrapper-3.1.0.jar
Resolving repo.maven.apache.org (repo.maven.apache.org)... 151.101.132.215
Connecting to repo.maven.apache.org
(repo.maven.apache.org)|151.101.132.215|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 58727 (57K) [application/java-archive]
Saving to: '/home/wrapper/api/.mvn/wrapper/maven-wrapper.jar'
/home/jorsol/Trabajo/conf-worksp
100%[==>] 57,35K
--.-KB/sin 0,007s
2021-12-21 11:52:44 (8,13 MB/s) -
'/home/wrapper/api/.mvn/wrapper/maven-wrapper.jar' saved [58727/58727]
11:52:45.544 [INFO] Scanning for projects...
...
{noformat}
Current output for *curl* the maven-wrapper.jar is missing:
{noformat}
./mvnw clean
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
100 58727 100 587270 0 1303k 0 --:--:-- --:--:-- --:--:-- 1303k
12:02:23.007 [INFO] Scanning for projects...
...
{noformat}
Current output for *MavenWrapperDownloader* when the maven-wrapper.jar is
missing:
{noformat}
./mvnw clean
- Downloader started
- Using base directory: /home/wrapper/api
- Downloading from:
https://repo.maven.apache.org/maven2/org/apache/maven/wrapper/maven-wrapper/3.1.0/maven-wrapper-3.1.0.jar
- Downloading to: /home/wrapper/api/.mvn/wrapper/maven-wrapper.jar
Done
11:50:21.599 [INFO] Scanning for projects...
...
{noformat}
Everything between the _./mvnw_ and the first _INFO_ is just unwanted verbosity.
was:
By default the wrapper must be quiet, if the maven-wrapper.jar is not found the
scripts try to download the jar using wget, curl or the
MavenWrapperDownloader.java.
The download process should only print the output when the MVNW_VERBOSE is set
to true.
> Download of jar must be quiet by default
>
>
> Key: MWRAPPER-43
> URL: https://issues.apache.org/jira/browse/MWRAPPER-43
> Project: Maven Wrapper
> Issue Type: Improvement
> Components: Maven Wrapper Scripts
>Affects Versions: 3.1.0
>Reporter: Jorge Solórzano
>Priority: Normal
>
> By default, the wrapper must be quiet, if the _maven-wrapper.jar_ is not
> found the scripts try to download the jar using {*}wget{*}, {*}curl{*}, or
> the {*}MavenWrapperDownloader{*}.java.
> The download process should only print the output when the +*MVNW_VERBOSE*+
> is set to true.
> Current output for *wget* when the maven-wrapper.jar is missing:
> {noformat}
> ./mvnw clean
> --2021-12-21 11:52:43--
> https://repo.maven.apache.org/maven2/org/apache/maven/wrapper/maven-wrapper/3.1.0/maven-wrapper-3.1.0.jar
> Resolving repo.maven.apache.org (repo.maven.apache.org)... 151.101.132.215
> Connecting to repo.maven.apache.org
> (repo.maven.apache.org)|151.101.132.215|:443... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 58727 (57K) [application/java-archive]
> Saving to: '/home/wrapper/api/.mvn/wrapper/maven-wrapper.jar'
> /home/jorsol/Trabajo/conf-worksp
> 100%[==>] 57,35K
> --.-KB/sin 0,007s
> 2021-12-21 11:52:44 (8,13 MB/s) -
> '/home/wrapper/api/.mvn/wrapper/maven-wrapper.jar' saved [58727/58727]
> 11:52:45.544 [INFO] Scanning for projects...
> ...
> {noformat}
> Current output for *curl* the maven-wrapper.jar is missing:
> {noformat}
> ./mvnw clean
> % Total% Received % Xferd Average Speed TimeTime Time
> Current
> Dload Upload Total SpentLeft Speed
> 100 58727 100 587270 0 1303k 0 --:--:-- --:--:-- --:--:-- 1303k
> 12:02:23.007 [INFO] Scanning for projects...
> ...
> {noformat}
> Current output for *MavenWrapperDownloader* when the maven-wrapper.jar is
> missing:
> {noformat}
> ./mvnw clean
> - Downloader started
> - Using base directory: /home/wrapper/api
> - Downloading from:
> https://repo.maven.apache.org/maven2/org/apache/maven/wrapper/maven-wrapper/3.1.0/maven-wrapper-3.1.0.jar
> - Downloading to: /home/wrapper/api/.mvn/wrapper/maven-wrapper.jar
> Done
> 11:50:21.599 [INFO] Scanning for projects...
> ...
> {noformat}
> Everything between the
[jira] [Commented] (MDEP-753) Non-test dependency reported as Non-test scoped test only dependency
[ https://issues.apache.org/jira/browse/MDEP-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463176#comment-17463176 ] Eivind Bergtøl commented on MDEP-753: - We are in the process of actually starting using java 17 now and this leaves us no choice but to set `false` for now and follow this thread more closely. If there are any thing I can do to help this progress I am glad to help. Also for testing, since we have other examples than the Guava-example above. > Non-test dependency reported as Non-test scoped test only dependency > > > Key: MDEP-753 > URL: https://issues.apache.org/jira/browse/MDEP-753 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: analyze >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > > Saw this when updating the google-http-java-client from 3.1.2 to 3.2.0 of the > plugin. I'm not immediately sure whether this is a regression: > [INFO] --- maven-dependency-plugin:3.2.0:analyze (default-cli) @ > google-http-client --- > Warning: Non-test scoped test only dependencies found: > Warning: com.google.guava:guava:jar:30.1.1-android:compile > Warning: io.opencensus:opencensus-api:jar:0.28.0:compile > Changing Guava to scope test breaks the build, which is expected based on the > code. The warning seems incorrect. > https://github.com/googleapis/google-http-java-client/pull/1396 > https://github.com/googleapis/google-http-java-client/pull/1396/checks?check_run_id=2809438131 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1916) thread blocked freezing progress
[ https://issues.apache.org/jira/browse/SUREFIRE-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463172#comment-17463172 ] Slawomir Jaranowski commented on SUREFIRE-1916: --- >From stack trace it looks like problem in slf4j-simple. Can be connected with: https://jira.qos.ch/browse/SLF4J-515 Fixed in Maven 3.8.2 - MNG-7198 > thread blocked freezing progress > > > Key: SUREFIRE-1916 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1916 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.22.2 > Environment: java -version > openjdk version "1.8.0_292" > OpenJDK Runtime Environment (Zulu 8.54.0.21-CA-win64) (build 1.8.0_292-b10) > OpenJDK 64-Bit Server VM (Zulu 8.54.0.21-CA-win64) (build 25.292-b10, mixed > mode) >Reporter: Peter Firmstone >Priority: Minor > > Thread live lock during reporting. I'll update to a later release, this is > very uncommon it's never happened before, just thought I'd report it here. > > 2021-06-03 12:16:36 > Full thread dump OpenJDK 64-Bit Server VM (25.292-b10 mixed mode): > "ThreadedStreamConsumer" #40 daemon prio=5 os_prio=0 tid=0x3cd46800 > nid=0x56b8 runnable [0x4118e000] > java.lang.Thread.State: RUNNABLE > at java.io.FileOutputStream.writeBytes(Native Method) > at java.io.FileOutputStream.write(FileOutputStream.java:326) > at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) > - locked <0x0003f2a966e0> (a java.io.BufferedOutputStream) > at java.io.PrintStream.write(PrintStream.java:482) > - locked <0x0003f2a966c0> (a java.io.PrintStream) > at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) > at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) > at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104) > - locked <0x0003f2a96808> (a java.io.OutputStreamWriter) > at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185) > at java.io.PrintStream.write(PrintStream.java:527) > - locked <0x0003f2a966c0> (a java.io.PrintStream) > at java.io.PrintStream.print(PrintStream.java:583) > at org.fusesource.jansi.FilterPrintStream.write(FilterPrintStream.java:99) > at org.fusesource.jansi.FilterPrintStream.write(FilterPrintStream.java:107) > at org.fusesource.jansi.FilterPrintStream.print(FilterPrintStream.java:156) > at org.fusesource.jansi.FilterPrintStream.println(FilterPrintStream.java:231) > - locked <0x0003f2a70188> (a org.fusesource.jansi.WindowsAnsiPrintStream) > at org.slf4j.impl.SimpleLogger.write(SimpleLogger.java:318) > at org.slf4j.impl.SimpleLogger.log(SimpleLogger.java:295) > at org.slf4j.impl.SimpleLogger.info(SimpleLogger.java:480) > at org.apache.maven.cli.logging.Slf4jLogger.info(Slf4jLogger.java:59) > at > org.apache.maven.plugin.surefire.log.PluginConsoleLogger.info(PluginConsoleLogger.java:77) > at > org.apache.maven.plugin.surefire.report.ConsoleReporter.println(ConsoleReporter.java:96) > at > org.apache.maven.plugin.surefire.report.ConsoleReporter.testSetCompleted(ConsoleReporter.java:74) > at > org.apache.maven.plugin.surefire.report.TestSetRunListener.testSetCompleted(TestSetRunListener.java:183) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.processLine(ForkClient.java:227) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:177) > at > org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:88) > at java.lang.Thread.run(Thread.java:748) > Locked ownable synchronizers: > - None > "ping-timer-10s" #39 daemon prio=5 os_prio=0 tid=0x3cd49800 > nid=0x5c54 waiting on condition [0x40e8f000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00067ff54578> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2044) > at > java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081) > at > java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) > at > java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Locked ownable
[GitHub] [maven] michael-o commented on pull request #602: Maven.config from start scripts
michael-o commented on pull request #602: URL: https://github.com/apache/maven/pull/602#issuecomment-998701868 This PR will be superseded with two alternatives as soon as #637 and #638 are 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] (SUREFIRE-1916) thread blocked freezing progress
[ https://issues.apache.org/jira/browse/SUREFIRE-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463168#comment-17463168 ] Peter Firmstone commented on SUREFIRE-1916: --- Just so you know, the concurrency bug will still be there, it'll probably be exposed again at a later date by improvements in the Java platform. -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. > thread blocked freezing progress > > > Key: SUREFIRE-1916 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1916 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.22.2 > Environment: java -version > openjdk version "1.8.0_292" > OpenJDK Runtime Environment (Zulu 8.54.0.21-CA-win64) (build 1.8.0_292-b10) > OpenJDK 64-Bit Server VM (Zulu 8.54.0.21-CA-win64) (build 25.292-b10, mixed > mode) >Reporter: Peter Firmstone >Priority: Minor > > Thread live lock during reporting. I'll update to a later release, this is > very uncommon it's never happened before, just thought I'd report it here. > > 2021-06-03 12:16:36 > Full thread dump OpenJDK 64-Bit Server VM (25.292-b10 mixed mode): > "ThreadedStreamConsumer" #40 daemon prio=5 os_prio=0 tid=0x3cd46800 > nid=0x56b8 runnable [0x4118e000] > java.lang.Thread.State: RUNNABLE > at java.io.FileOutputStream.writeBytes(Native Method) > at java.io.FileOutputStream.write(FileOutputStream.java:326) > at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) > - locked <0x0003f2a966e0> (a java.io.BufferedOutputStream) > at java.io.PrintStream.write(PrintStream.java:482) > - locked <0x0003f2a966c0> (a java.io.PrintStream) > at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) > at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) > at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104) > - locked <0x0003f2a96808> (a java.io.OutputStreamWriter) > at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185) > at java.io.PrintStream.write(PrintStream.java:527) > - locked <0x0003f2a966c0> (a java.io.PrintStream) > at java.io.PrintStream.print(PrintStream.java:583) > at org.fusesource.jansi.FilterPrintStream.write(FilterPrintStream.java:99) > at org.fusesource.jansi.FilterPrintStream.write(FilterPrintStream.java:107) > at org.fusesource.jansi.FilterPrintStream.print(FilterPrintStream.java:156) > at org.fusesource.jansi.FilterPrintStream.println(FilterPrintStream.java:231) > - locked <0x0003f2a70188> (a org.fusesource.jansi.WindowsAnsiPrintStream) > at org.slf4j.impl.SimpleLogger.write(SimpleLogger.java:318) > at org.slf4j.impl.SimpleLogger.log(SimpleLogger.java:295) > at org.slf4j.impl.SimpleLogger.info(SimpleLogger.java:480) > at org.apache.maven.cli.logging.Slf4jLogger.info(Slf4jLogger.java:59) > at > org.apache.maven.plugin.surefire.log.PluginConsoleLogger.info(PluginConsoleLogger.java:77) > at > org.apache.maven.plugin.surefire.report.ConsoleReporter.println(ConsoleReporter.java:96) > at > org.apache.maven.plugin.surefire.report.ConsoleReporter.testSetCompleted(ConsoleReporter.java:74) > at > org.apache.maven.plugin.surefire.report.TestSetRunListener.testSetCompleted(TestSetRunListener.java:183) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.processLine(ForkClient.java:227) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:177) > at > org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:88) > at java.lang.Thread.run(Thread.java:748) > Locked ownable synchronizers: > - None > "ping-timer-10s" #39 daemon prio=5 os_prio=0 tid=0x3cd49800 > nid=0x5c54 waiting on condition [0x40e8f000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00067ff54578> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2044) > at > java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081) > at > java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) > at > java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) > at >
[GitHub] [maven] michael-o commented on a change in pull request #637: [MNG-7193] Introduce MAVEN_ARGS environment variable
michael-o commented on a change in pull request #637: URL: https://github.com/apache/maven/pull/637#discussion_r772945412 ## File path: apache-maven/src/assembly/shared/validate.cmd ## @@ -24,6 +24,7 @@ @REM MAVEN_BATCH_ECHO (Optional) Set to 'on' to enable the echoing of the batch commands. @REM MAVEN_BATCH_PAUSE (Optional) set to 'on' to wait for a key stroke before ending. @REM MAVEN_OPTS(Optional) Java runtime options used when Maven is executed. +@REM MAVEN_ARGS(Optional) Arguments passed to Maven before CLI arguments. Review comment: While you may be right I think they sorted logically by usage. I make it alphabetically, no issue. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] rfscholte commented on a change in pull request #637: [MNG-7193] Introduce MAVEN_ARGS environment variable
rfscholte commented on a change in pull request #637: URL: https://github.com/apache/maven/pull/637#discussion_r772943450 ## File path: apache-maven/src/assembly/shared/validate.cmd ## @@ -24,6 +24,7 @@ @REM MAVEN_BATCH_ECHO (Optional) Set to 'on' to enable the echoing of the batch commands. @REM MAVEN_BATCH_PAUSE (Optional) set to 'on' to wait for a key stroke before ending. @REM MAVEN_OPTS(Optional) Java runtime options used when Maven is executed. +@REM MAVEN_ARGS(Optional) Arguments passed to Maven before CLI arguments. Review comment: Assuming these are in alphabetic order, this is not the right location -- 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-resolver] caiwei-ebay edited a comment on pull request #136: [MRESOLVER-228] skip & reconcile
caiwei-ebay edited a comment on pull request #136: URL: https://github.com/apache/maven-resolver/pull/136#issuecomment-998529747 @michael-o @cstamas Squashed the commits. Simplified the algorithm a lot. I have verified this approach by dry-run 2000+ apps in our company. Compared with previous approach: 1. Use a simpler approach to find out the nodes to reconcile. [Here](https://github.com/apache/maven-resolver/pull/136/files#diff-acdb4a279ff4d0407eaa7ee1767897eb62fbd0def455e06701f5ff81f8d3e938R281) The overall idea is: `Skip -> Reconcile (Transform rehearsal) -> Transform graph ` **Skip:** Skip resolving the node if a node with the same GAV and lower (or equal) depth has been calculated before. [Here](https://github.com/apache/maven-resolver/pull/136/files#diff-36be580aa73363c9aa07eb3954c331fb94da0906d7d0b4585bd18ab7c1305632R579) Sample: - A -> B -> C (C calculated and cached with depth==3) - A -> E -> F -> C (C will be skipped and children is not set, record this C has been skipped by above C node) - A -> C (C re-calculated and cached with depth==2) - A -> K -> C (C will be skipped, record this C has been skipped by the C node with path A -> C) With skip step only, the "mvn dependency:tree -Dverbose" is already guaranteed to be identical, however the "mvn dependency:tree" or "mvn dependency:list" result might be impacted as there would be dependency conflicts. At the very first, I just implemented the Skip strategy and tested with 500+ apps, 99%+ apps were having identical "mvn dependency:tree" or "mvn dependency:list" result, only 4 apps failed as there are dependency version conflicts. This is why we need the reconcile strategy as below. **Reconcile (Transform rehearsal):** `Clone the root node recursively -> Call transformer to transform the cloned root node -> Get the conflicts & the nodes to reconcile -> house sweeping for the NodesWithDepth cache -> reconcile the nodes` > 99%+ of apps don't need to a reconcile as the node needs to be reconcile is empty. Sample: - A -> B -> C 3.0 -> D -> Z(D of C 3.0 calculated and cached with depth==4) - A -> E ->F -> G -> D -> Z (D will be skipped and children is not set because depth 5 is deeper, record this D has been skipped by above D node) - A -> C 2.0 ->H (C 2.0 comes to resolve and maven will pick C 2.0 as depth is lower. The D of C3.0 in step 1 is no longer valid, need reconcile the skipped D node in step 2) Here is the flow: 1. Get the cloned root node A by deep cloning the original root node, the original root node has already been applied above skip strategy. [Here](https://github.com/apache/maven-resolver/pull/136/files#diff-acdb4a279ff4d0407eaa7ee1767897eb62fbd0def455e06701f5ff81f8d3e938R151) ``` A -> B -> C 3.0 -> D -> Z A -> E ->F -> G -> D (D has no children as skipped) A -> C 2.0 ->H ``` 2. Call Session's transformer to transform the cloned root node A with verbose mode, note transformer will set children as empty for conflict losers (ConflictResolver.removeLosers). [Here](https://github.com/apache/maven-resolver/pull/136/files#diff-acdb4a279ff4d0407eaa7ee1767897eb62fbd0def455e06701f5ff81f8d3e938R158) ``` A -> B -> C 3.0(C 3.0 has no children as chopped by transformer, marked as conflict resolver) A -> E ->F -> G -> D (D has no children as skipped) A -> C 2.0 ->H ``` 3. Use ReconclingClonedGraphVisitor to iterate the transformed cloned root node. When visitor comes to a node without children, it can either a skipped node with no children set or chopped by transformer in step 2. [Here](https://github.com/apache/maven-resolver/pull/136/files#diff-acdb4a279ff4d0407eaa7ee1767897eb62fbd0def455e06701f5ff81f8d3e938R175) We just need to reconcile all skipped nodes (the node has no children and children of original node before transform is also empty). `D (parent path A -> E -> F -> G) needs to be reconciled` The visitor also record the dependency conflicts according to the ConflictResolver.NODE_DATA_WINNER property. `C 2.0 conflicts with C 3.0` 4. Remove cached items from nodesWithDepth if the parent paths of current node includes any above conflict loser: C 2.0. [Here](https://github.com/apache/maven-resolver/pull/136/files#diff-acdb4a279ff4d0407eaa7ee1767897eb62fbd0def455e06701f5ff81f8d3e938R201) ``` remove D (children Z， parent path A -> B -> C3.0) from nodesWithDepth remove Z (parent path A -> B -> C3.0 -> D) from nodesWithDepth ``` 5. Reconcile the nodes (recalculate their children) found in step 3.
[GitHub] [maven] michael-o commented on pull request #637: [MNG-7193] Introduce MAVEN_ARGS environment variable
michael-o commented on pull request #637: URL: https://github.com/apache/maven/pull/637#issuecomment-998582931 @rfscholte Updated inline scripts and add https://github.com/apache/maven-site/pull/280. -- 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] (MRESOLVER-228) Improve the maven dependency resolution speed by a skip & reconcile approach
[
https://issues.apache.org/jira/browse/MRESOLVER-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463042#comment-17463042
]
wei cai edited comment on MRESOLVER-228 at 12/21/21, 8:31 AM:
--
[~michael-o]
Details of the simplified algorithm:
[https://github.com/apache/maven-resolver/pull/136#issuecomment-998529747]
Originally was trying to filter out the least nodes to be reconciled from
thousands of skipped nodes. With the updated algorithm, it can quickly locate
the nodes to be reconciled by walking through the cloned graph.
The nodes need to be reconciled should satisfy:
* A selected node:
Node is a selected node (no winner set in DependencyNode.getData) which means
this node is being selected by maven.
* No children:
Node has no children & original node also has no children (Skipped by other
nodes with lower depth previously).
The overall idea is:
Skip -> Reconcile (Transform rehearsal) -> Transform graph
*Skip:*
Skip resolving if node has deeper depth than cached when resolving all nodes
from the root following up the original depth-first strategy.
*Reconcile (Transform rehearsal):*
1. Cloned the nodes -> Transformer to transform the cloned root node -> Get
the conflicts & the nodes to reconcile.
2. Do some house sweeping for the NodesWithDepth cache, and reconcile the nodes
in above step.
99%+ of apps don't need to a reconcile as the nodes found in above step is
empty.
was (Author: wecai):
[~michael-o]
Details of the updated algorithm
https://github.com/apache/maven-resolver/pull/136#issuecomment-998529747
> Improve the maven dependency resolution speed by a skip & reconcile approach
>
>
> Key: MRESOLVER-228
> URL: https://issues.apache.org/jira/browse/MRESOLVER-228
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 1.7.2
>Reporter: wei cai
>Priority: Major
> Fix For: 1.8.0
>
> Attachments: Screen Shot 2021-11-27 at 12.58.26 PM.png, Screen Shot
> 2021-11-27 at 12.58.59 PM.png, Screen Shot 2021-11-27 at 12.59.32 PM.png
>
>
> When comes to resolve the huge amount of dependencies of an enterprise level
> project, the maven resolver is very slow to resolve the dependency
> graph/tree. Take one of our app as example, it could take *10minutes+ and 16G
> memory* to print out the result of {*}mvn dependency:tree{*}.
> This is because there are many dependencies declared in the project, and some
> of the dependencies would introduce *600+* transitive dependencies, and
> exclusions are widely used to solve dependency conflicts.
> By checking the
> [code|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L500],
> we know the exclusion is also part of the cache key. This means when the
> exclusions up the tree differs, the cached resolution result for the same GAV
> won't be picked up and need s to be recalculated.
> !Screen Shot 2021-11-27 at 12.58.26 PM.png!
> From above figure, we know:
> * In 1st case, D will be resolved only once as there are no exclusions/same
> exclusions up the tree.
> * In 2nd case, the B and C have different exclusions and D needs to be
> recalculated, if D is a heavy dependency which introduce many transitive
> dependencies, all D and its children needs to be recalculated. Recalculating
> all of these nodes introduces 2 issues:
> ** Slow in resolving dependencies.
> ** Lots of DependencyNodes cached (all calculated/recalculated nodes would
> be cached) and will consume huge memory.
> To improve the speed of maven resolver's dependency resolution, I
> implemented a skip & reconcile approach. Here is the *skip* part.
> !Screen Shot 2021-11-27 at 12.58.59 PM.png!
> From above figure, the 1st R is resolved at depth 3, and the 2nd R is
> resolved again because the depth is at 2 which is lower, the 3rd R at depth 3
> and the 4th R at depth 4 are simply skipped as R is already resolved at depth
> 2. This is because the same node with deeper depth is most likely won't be
> picked up by maven as maven employs a "{*}nearest{*} transitive dependency in
> the tree depth and the *first* in resolution" strategy.
> The 3rd R and 4th R will have children set as zero and marked as skipped by
> the R at depth 2 in 2nd tree path.
>
> Here is the *reconcile* part:
> !Screen Shot 2021-11-27 at 12.59.32 PM.png!
> When there are dependency conflicts, some of the skipped nodes need to be
> reconciled.
> In above figure, there are 4 tree paths.
> * The D1 (D with version 1) in the 1st tree path is get resolved, children
> of E and R at depth 3 are resolved and cached.
> * In the 2nd tree path, when
[GitHub] [maven-resolver] caiwei-ebay edited a comment on pull request #136: [MRESOLVER-228] skip & reconcile
caiwei-ebay edited a comment on pull request #136: URL: https://github.com/apache/maven-resolver/pull/136#issuecomment-998529747 @michael-o @cstamas Squashed the commits. Simplified the algorithm a lot. I have verified this approach by dry-run 2000+ apps in our company. Compared with previous approach: 1. Use a simpler approach to find out the nodes to reconcile. [Here](https://github.com/apache/maven-resolver/pull/136/files#diff-acdb4a279ff4d0407eaa7ee1767897eb62fbd0def455e06701f5ff81f8d3e938R281) **Skip:** Skip resolving the node if a node with the same GAV and lower (or equal) depth has been calculated before. [Here](https://github.com/apache/maven-resolver/pull/136/files#diff-36be580aa73363c9aa07eb3954c331fb94da0906d7d0b4585bd18ab7c1305632R579) Sample: - A -> B -> C (C calculated and cached with depth==3) - A -> E -> F -> C (C will be skipped and children is not set, record this C has been skipped by above C node) - A -> C (C re-calculated and cached with depth==2) - A -> K -> C (C will be skipped, record this C has been skipped by the C node with path A -> C) With skip step only, the "mvn dependency:tree -Dverbose" is already guaranteed to be identical, however the "mvn dependency:tree" or "mvn dependency:list" result might be impacted as there would be dependency conflicts. At the very first, I just implemented the Skip strategy and tested with 500+ apps, 99%+ apps were having identical "mvn dependency:tree" or "mvn dependency:list" result, only 4 apps failed as there are dependency version conflicts. This is why we need the reconcile strategy as below. **Reconcile:** - A -> B -> C 3.0 -> D -> Z(D of C 3.0 calculated and cached with depth==4) - A -> E ->F -> G -> D -> Z (D will be skipped and children is not set because depth 5 is deeper, record this D has been skipped by above D node) - A -> C 2.0 ->H (C 2.0 comes to resolve and maven will pick C 2.0 as depth is lower. The D of C3.0 in step 1 is no longer valid, need reconcile the skipped D node in step 2) Here is the flow: 1. Get the cloned root node A by deep cloning the original root node, the original root node has already been applied above skip strategy. [Here](https://github.com/apache/maven-resolver/pull/136/files#diff-acdb4a279ff4d0407eaa7ee1767897eb62fbd0def455e06701f5ff81f8d3e938R151) ``` A -> B -> C 3.0 -> D -> Z A -> E ->F -> G -> D (D has no children as skipped) A -> C 2.0 ->H ``` 2. Call Session's transformer to transform the cloned root node A with verbose mode, note transformer will set children as empty for conflict losers (ConflictResolver.removeLosers). [Here](https://github.com/apache/maven-resolver/pull/136/files#diff-acdb4a279ff4d0407eaa7ee1767897eb62fbd0def455e06701f5ff81f8d3e938R158) ``` A -> B -> C 3.0(C 3.0 has no children as chopped by transformer) A -> E ->F -> G -> D (D has no children as skipped) A -> C 2.0 ->H ``` 3. Use ReconclingClonedGraphVisitor to iterate the transformed cloned root node. When visitor comes to a node without children, it can either a skipped node with no children set or chopped by transformer in step 2. [Here](https://github.com/apache/maven-resolver/pull/136/files#diff-acdb4a279ff4d0407eaa7ee1767897eb62fbd0def455e06701f5ff81f8d3e938R175) We just need to reconcile all skipped nodes (the node has no children and children of original node before transform is also empty). `D (parent path A -> E -> F -> G) needs to be reconciled` The visitor also record the dependency conflicts according to the ConflictResolver.NODE_DATA_WINNER property. `C 2.0 conflicts with C 3.0` 4. Remove cached items from nodesWithDepth if the parent paths of current node includes any above conflict losers. [Here](https://github.com/apache/maven-resolver/pull/136/files#diff-acdb4a279ff4d0407eaa7ee1767897eb62fbd0def455e06701f5ff81f8d3e938R201) ``` remove D (children Z， parent path A -> B -> C3.0) from nodesWithDepth remove Z (parent path A -> B -> C3.0 -> D) from nodesWithDepth ``` 5. Reconcile the nodes (recalculate their children) found in step 3. [Here](https://github.com/apache/maven-resolver/pull/136/files#diff-36be580aa73363c9aa07eb3954c331fb94da0906d7d0b4585bd18ab7c1305632R292) `recalculate D (parent path A -> E -> F -> G, skipped by A -> B -> C3.0 -> D)` -- 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:
[GitHub] [maven] michael-o commented on pull request #637: [MNG-7193] Introduce MAVEN_ARGS environment variable
michael-o commented on pull request #637: URL: https://github.com/apache/maven/pull/637#issuecomment-998558401 > I will supersede #602 with two alternative PRs. -- 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-7366) Maven downloading log4j version not specified in POM when building the Project.
[
https://issues.apache.org/jira/browse/MNG-7366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463054#comment-17463054
]
Maarten Mulders commented on MNG-7366:
--
As said before:
{quote}By the way, the fact that Maven downloads a particular JAR is in itself
not a critical security issue.
{quote}
Because as long as Log4J is not loaded by the application you package, deploy
or run, nobody will be able to exploit any issue in Log4J.
> Maven downloading log4j version not specified in POM when building the
> Project.
> ---
>
> Key: MNG-7366
> URL: https://issues.apache.org/jira/browse/MNG-7366
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.8.4
>Reporter: Srinivasan L
>Priority: Critical
> Attachments: maven log4j issue.png
>
>
> Maven downloading log4j version not specified in POM when building the
> Project.
> In POM i have updated my log4j to log4j core 2.16.0 to fix the Log4j
> Vulnerability with Older version. But even after changing the Version Maven
> is downloading 1.2.12 and 1.2.17 version of Log4j when running the build.
> I'm not seeing these version even in the dependency tree of my Project.
> Please help to fix this issue as its a Critical Security Issue.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
