[GitHub] [maven-integration-testing] slawekjaranowski merged pull request #145: Fix tests on JDK 1.7 - setup TLS protocol for verifier
slawekjaranowski merged PR #145: URL: https://github.com/apache/maven-integration-testing/pull/145 -- 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] cstamas commented on pull request #161: [MRESOLVER-248] Make BF and DF collectors coexists
cstamas commented on PR #161: URL: https://github.com/apache/maven-resolver/pull/161#issuecomment-1092462803 Right, doco changes are missing (2 new config keys), will add them -- 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-apache-parent] dependabot[bot] opened a new pull request, #77: Bump maven-clean-plugin from 3.1.0 to 3.2.0
dependabot[bot] opened a new pull request, #77: URL: https://github.com/apache/maven-apache-parent/pull/77 Bumps [maven-clean-plugin](https://github.com/apache/maven-clean-plugin) from 3.1.0 to 3.2.0. Commits https://github.com/apache/maven-clean-plugin/commit/831fe7b5dcc62ce3479016f14776da895585e769;>831fe7b [maven-release-plugin] prepare release maven-clean-plugin-3.2.0 https://github.com/apache/maven-clean-plugin/commit/2dd1e2f71575fb817ea6686d899b9793b9deaf15;>2dd1e2f Revert [maven-release-plugin] prepare release maven-clean-plugin-3.2.0 https://github.com/apache/maven-clean-plugin/commit/78563f02bd52aee6d1603436354f822aaa8148db;>78563f0 [maven-release-plugin] prepare release maven-clean-plugin-3.2.0 https://github.com/apache/maven-clean-plugin/commit/57a207360c379d2284fde1220094ccbba45fdf44;>57a2073 Revert [maven-release-plugin] prepare release maven-clean-plugin-3.2.0 https://github.com/apache/maven-clean-plugin/commit/eda48402526337494191d5f58b620a03e0291d4a;>eda4840 Revert [maven-release-plugin] prepare for next development iteration https://github.com/apache/maven-clean-plugin/commit/4424efaed161c662875a1e1937ad7dbf186b6cc6;>4424efa [maven-release-plugin] prepare for next development iteration https://github.com/apache/maven-clean-plugin/commit/ec9d6e88c4f47f87a6e421b489dd15b416a274ae;>ec9d6e8 [maven-release-plugin] prepare release maven-clean-plugin-3.2.0 https://github.com/apache/maven-clean-plugin/commit/81b7e248d2c3a529498884346272cd7105305f3e;>81b7e24 [MCLEAN-98] - Upgrade maven-plugin parent to 35 https://github.com/apache/maven-clean-plugin/commit/ed958d4780339e50fbad22404c4e9db56f55eab1;>ed958d4 Shared GitHub actions v2 https://github.com/apache/maven-clean-plugin/commit/11c8c872d808e3ff4d24e275f63c8cc35fb9e137;>11c8c87 [MCLEAN-95] Add a fast clean option (https://github-redirect.dependabot.com/apache/maven-clean-plugin/issues/6;>#6) Additional commits viewable in https://github.com/apache/maven-clean-plugin/compare/maven-clean-plugin-3.1.0...maven-clean-plugin-3.2.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 this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-doxia-converter] dependabot[bot] opened a new pull request, #24: Bump icu4j from 70.1 to 71.1
dependabot[bot] opened a new pull request, #24: URL: https://github.com/apache/maven-doxia-converter/pull/24 Bumps [icu4j](https://github.com/unicode-org/icu) from 70.1 to 71.1. Release notes Sourced from https://github.com/unicode-org/icu/releases;>icu4j's releases. ICU 71.1 We are pleased to announce the release of Unicode® ICU 71. ICU 71 updates to https://cldr.unicode.org/index/downloads/cldr-41;>CLDR 41 locale data with various additions and corrections. ICU 71 adds phrase-based line breaking for Japanese. Existing line breaking methods follow standards and conventions for body text but do not work well for short Japanese text, such as in titles and headings. This new feature is optimized for these use cases. ICU 71 adds support for Hindi written in Latin letters (hi_Latn). The CLDR data for this increasingly popular locale has been significantly revised and expanded. Note that based on user expectations, hi_Latn incorporates a large amount of English, and can also be referred to as “Hinglish”. ICU 71 and CLDR 41 are minor releases, mostly focused on bug fixes and small enhancements. (The fall CLDR/ICU releases will update to Unicode 15 which is planned for September.) We are also working to re-establish continuous performance testing for ICU, and on development towards future versions. ICU 71 updates to the time zone data version 2022a. Note that pre-1970 data for a number of time zones has been removed, as has been the case in the upstream https://www.iana.org/time-zones;>tzdata release since 2021b. For details, please see https://icu.unicode.org/download/71;>https://icu.unicode.org/download/71. Note: Our website has moved. Please adjust your bookmarks. The API reference documents are published at the following location: https://unicode-org.github.io/icu-docs/;>https://unicode-org.github.io/icu-docs/ Note: The prebuilt WinARM64 binaries below should be considered alpha/experimental. ICU 71 RC We are pleased to announce the release candidate for Unicode® ICU 71. ICU 71 updates to https://cldr.unicode.org/index/downloads/cldr-41;>CLDR 41 locale data with various additions and corrections, and adds phrase-based line breaking for Japanese. ICU 71 also includes a number of other bug fixes and enhancements, and we are working to re-establish continuous performance testing. ICU 71 updates to the time zone data version 2022a. Note that pre-1970 data for a number of time zones has been removed, as has been the case in the upstream tzdata release since 2021b. For details, please see https://icu.unicode.org/download/71;>https://icu.unicode.org/download/71. Note: Our website has moved. Please adjust your bookmarks. Please test this release candidate on your platforms and report bugs and regressions by Tuesday, 2022-apr-05, via the http://site.icu-project.org/contacts;>icu-support mailing list, and/or please https://icu.unicode.org/bugs;>find/submit error reports. Please do not use this release candidate in production. The release candidate API reference documents are published on https://unicode-org.github.io/icu-docs/;>https://unicode-org.github.io/icu-docs/ – follow the “Dev” links there. Note: The prebuilt WinARM64 binaries below should be considered alpha/experimental. Commits See full diff in https://github.com/unicode-org/icu/commits;>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 this minor version` will close this PR and stop
[GitHub] [maven-resolver] kwin commented on pull request #161: [MRESOLVER-248] Make BF and DF collectors coexists
kwin commented on PR #161: URL: https://github.com/apache/maven-resolver/pull/161#issuecomment-1092417102 Can you outline how to toggle at https://github.com/apache/maven-resolver/blob/master/src/site/markdown/configuration.md? -- 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] (MNG-7433) [REGRESSION] Multiple maven instances working on same source tree can lock each other
[
https://issues.apache.org/jira/browse/MNG-7433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519165#comment-17519165
]
Dan Tran edited comment on MNG-7433 at 4/8/22 3:18 AM:
---
here is a brief just to visualize the issue and its steps
{code:java}
10:59:16 [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
xxx-mvnrepo ---
10:59:16 [INFO]
10:59:16 [INFO] --< com.xxx.xxx.xxx:sonar-analysis
>--
10:59:16 [INFO] Building sonar-analysis 19.11.0-1-SNAPSHOT
[538/540]
10:59:16 [INFO] [ pom
]-
10:59:16 [INFO]
10:59:16 [INFO] ---< com.xxx.xxx.xxx.installer:xxx-puppet-config
>
10:59:16 [INFO] Building xxx-puppet-config 19.11.0-1-SNAPSHOT
[539/540]
10:59:16 [INFO] [ rpm
]-
10:59:16 [INFO]
10:59:16 [INFO] --- maven-enforcer-plugin:1.4.1:enforce (default) @
sonar-analysis ---
10:59:16 [INFO]
10:59:16 [INFO] --- jacoco-maven-plugin:0.8.7:prepare-agent (jacoco-all) @
sonar-analysis ---
10:59:16 [INFO] argLine set to
-javaagent:/space/jenkins/workspace/xxx_xxx_xxx_PR-4236/.repository/org/jacoco/org.jacoco.agent/0.8.7/org.jacoco.agent-0.8.7-runtime.jar=destfile=/space/jenkins/workspace/xxx_xxx_xxx_PR-4236/sonar/target/jacoco.exec
10:59:16 [INFO]
10:59:16 [INFO] --- flatten-maven-plugin:1.2.7:flatten (flatten) @
sonar-analysis ---
10:59:16 [INFO] Generating flattened POM of project
com.xxx.xxx.xxx:sonar-analysis:pom:19.11.0-1-SNAPSHOT...
10:59:16 [INFO]
10:59:16 [INFO] --- jacoco-maven-plugin:0.8.7:report (jacoco-all) @
sonar-analysis ---
10:59:16 [INFO] Skipping JaCoCo execution due to missing execution data file.
10:59:20 [INFO]
10:59:20 [INFO] --- maven-enforcer-plugin:1.4.1:enforce (default) @
xxx-puppet-config ---
10:59:20 [INFO]
10:59:20 [INFO] --- mdev-maven-plugin:1.6.3:sonar
(quiet-sonar-scan-by-default) @ sonar-analysis ---
10:59:20 [INFO] Executing: /bin/sh -c cd
'/space/jenkins/workspace/xxx_xxx_xxx_PR-4236' &&
'/xxx/build/.m2/wrapper/dists/apache-maven-3.8.5-bin/5sf9ufumnhp6odg6f4svjl54q1/apache-maven-3.8.5/bin/mvn'
'-ntp' 'sonar:sonar' '-Dsonar.pullrequest.key=4236'
'-Dsonar.pullrequest.branch=personal/trand8/maven-3.8.5-2'
'-Dsonar.pullrequest.base=master' '--quiet' '-P!sonar' '-s'
'/tmp/settings43566726mvn'. Working directory:
/space/jenkins/workspace/xxx_xxx_xxx_PR-4236
{code}
it shows - after xxx-mvnrepos is done, 2 modules are then run in parallel:
sonar-analysis and xxx-puppet-config. The xxx-puppet-config stalls after
sonar-analisys spins another maven instant to run sonar:sonar
Note I can replace sonar:sonar with other goal such as 'compile' and see same
blocking issue
was (Author: dantran):
here is a brief just to visualize the issue and its steps
{code:java}
10:59:16 [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
xxx-mvnrepo ---
10:59:16 [INFO]
10:59:16 [INFO] --< com.xxx.xxx.xxx:sonar-analysis
>--
10:59:16 [INFO] Building sonar-analysis 19.11.0-1-SNAPSHOT
[538/540]
10:59:16 [INFO] [ pom
]-
10:59:16 [INFO]
10:59:16 [INFO] ---< com.xxx.xxx.xxx.installer:xxx-puppet-config
>
10:59:16 [INFO] Building xxx-puppet-config 19.11.0-1-SNAPSHOT
[539/540]
10:59:16 [INFO] [ rpm
]-
10:59:16 [INFO]
10:59:16 [INFO] --- maven-enforcer-plugin:1.4.1:enforce (default) @
sonar-analysis ---
10:59:16 [INFO]
10:59:16 [INFO] --- jacoco-maven-plugin:0.8.7:prepare-agent (jacoco-all) @
sonar-analysis ---
10:59:16 [INFO] argLine set to
-javaagent:/space/jenkins/workspace/xxx_xxx_xxx_PR-4236/.repository/org/jacoco/org.jacoco.agent/0.8.7/org.jacoco.agent-0.8.7-runtime.jar=destfile=/space/jenkins/workspace/xxx_xxx_xxx_PR-4236/sonar/target/jacoco.exec
10:59:16 [INFO]
10:59:16 [INFO] --- flatten-maven-plugin:1.2.7:flatten (flatten) @
sonar-analysis ---
10:59:16 [INFO] Generating flattened POM of project
com.xxx.xxx.xxx:sonar-analysis:pom:19.11.0-1-SNAPSHOT...
10:59:16 [INFO]
10:59:16 [INFO] --- jacoco-maven-plugin:0.8.7:report (jacoco-all) @
sonar-analysis ---
10:59:16 [INFO] Skipping JaCoCo execution due to missing execution data file.
10:59:20 [INFO]
10:59:20 [INFO] --- maven-enforcer-plugin:1.4.1:enforce (default) @
xxx-puppet-config ---
10:59:20 [INFO]
10:59:20 [INFO] --- mdev-maven-plugin:1.6.3:sonar
(quiet-sonar-scan-by-default) @ sonar-analysis ---
10:59:20 [INFO] Executing: /bin/sh -c cd
'/space/jenkins/workspace/xxx_xxx_xxx_PR-4236' &&
'/xxx/build/.m2/wrapper/dists/apache-maven-3.8.5-bin/5sf9ufumnhp6odg6f4svjl54q1/apache-maven-3.8.5/bin/mvn'
'-ntp'
[jira] [Commented] (SUREFIRE-1890) Not compatible with TestNG 7.4.0
[
https://issues.apache.org/jira/browse/SUREFIRE-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519257#comment-17519257
]
Scott Babcock commented on SUREFIRE-1890:
-
Issue logged:
[SUREFIRE-2064|https://issues.apache.org/jira/browse/SUREFIRE-2064]
Pull request: [#517|https://github.com/apache/maven-surefire/pull/517]
> Not compatible with TestNG 7.4.0
>
>
> Key: SUREFIRE-1890
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1890
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 3.0.0-M5
>Reporter: Joe Barnett
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
>
> TestNG 7.4.0 removed the deprecated method
> {{org.testng.xml.XmlSuite.setParallel(java.lang.String)}}. Trying to run
> tests with parallelism set results in:
> {code:java}
> java.lang.NoSuchMethodError: 'void
> org.testng.xml.XmlSuite.setParallel(java.lang.String)'
> at
> org.apache.maven.surefire.testng.conf.TestNGMapConfigurator.configure(TestNGMapConfigurator.java:71)
> at
> org.apache.maven.surefire.testng.conf.TestNG510Configurator.configure(TestNG510Configurator.java:40)
> at
> org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:111)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeSingleClass(TestNGDirectoryTestSuite.java:112)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:99)
> at
> org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:145)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] sbabcoc opened a new pull request, #517: [SUREFIRE-2064] Allow all supported values of [parallel] option
sbabcoc opened a new pull request, #517: URL: https://github.com/apache/maven-surefire/pull/517 This pull request revises the handling of the TestNG 7.4+ [parallel] option so that it accepts all valid values. Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SUREFIRE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the integration tests successfully (`mvn -Prun-its clean install`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (SUREFIRE-2064) Implementation of TestNG "parallel" option fails with default value
Scott Babcock created SUREFIRE-2064:
---
Summary: Implementation of TestNG "parallel" option fails with
default value
Key: SUREFIRE-2064
URL: https://issues.apache.org/jira/browse/SUREFIRE-2064
Project: Maven Surefire
Issue Type: Bug
Components: TestNG support
Affects Versions: 3.0.0-M6
Reporter: Scott Babcock
The latest release of Maven Surefire attempts to resolve an incompatibility
with TestNG 7.4+, but the way the fix was implemented causes projects that
don't specify parallel execution to fail:
{code:java}
[ERROR] There was an error in the forked process
[ERROR] Unsupported TestNG parallel setting: none ( only METHODS or CLASSES
supported )
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There was
an error in the forked process
[ERROR] Unsupported TestNG parallel setting: none ( only METHODS or CLASSES
supported )
{code}
"none" is the default value that gets passed in if no [parallel] setting is
specified. TestNG actually supports NONE as a valid value, along with TESTS and
INSTANCES. There are two deprecated values as well (TRUE and FALSE), which
cause TestNG to log a warning and translate to equivalent supported values
(METHODS and NONE respectively).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (SUREFIRE-1890) Not compatible with TestNG 7.4.0
[
https://issues.apache.org/jira/browse/SUREFIRE-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519246#comment-17519246
]
Scott Babcock edited comment on SUREFIRE-1890 at 4/8/22 12:42 AM:
--
This is a blocker... My POM doesn't specify at all, and the option
ends up with the default value "none", which gets rejected by this code as
invalid. I'm working on a pull request now, hoping to submit this later today.
was (Author: scoba):
This is a blocker... My POM doesn't specify at all, and the options
ends up with the default value "none", which gets rejected by this code as
invalid. I'm working on a pull request now, hoping to submit this later today.
> Not compatible with TestNG 7.4.0
>
>
> Key: SUREFIRE-1890
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1890
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 3.0.0-M5
>Reporter: Joe Barnett
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
>
> TestNG 7.4.0 removed the deprecated method
> {{org.testng.xml.XmlSuite.setParallel(java.lang.String)}}. Trying to run
> tests with parallelism set results in:
> {code:java}
> java.lang.NoSuchMethodError: 'void
> org.testng.xml.XmlSuite.setParallel(java.lang.String)'
> at
> org.apache.maven.surefire.testng.conf.TestNGMapConfigurator.configure(TestNGMapConfigurator.java:71)
> at
> org.apache.maven.surefire.testng.conf.TestNG510Configurator.configure(TestNG510Configurator.java:40)
> at
> org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:111)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeSingleClass(TestNGDirectoryTestSuite.java:112)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:99)
> at
> org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:145)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (SUREFIRE-1890) Not compatible with TestNG 7.4.0
[
https://issues.apache.org/jira/browse/SUREFIRE-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519246#comment-17519246
]
Scott Babcock edited comment on SUREFIRE-1890 at 4/8/22 12:41 AM:
--
This is a blocker... My POM doesn't specify at all, and the options
ends up with the default value "none", which gets rejected by this code as
invalid. I'm working on a pull request now, hoping to submit this later today.
was (Author: scoba):
This is a blocker... My POM doesn't specify at all, and it defaults
to "none", which gets rejected by this code as invalid. I'm working on a pull
request now, hoping to submit this later today.
> Not compatible with TestNG 7.4.0
>
>
> Key: SUREFIRE-1890
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1890
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 3.0.0-M5
>Reporter: Joe Barnett
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
>
> TestNG 7.4.0 removed the deprecated method
> {{org.testng.xml.XmlSuite.setParallel(java.lang.String)}}. Trying to run
> tests with parallelism set results in:
> {code:java}
> java.lang.NoSuchMethodError: 'void
> org.testng.xml.XmlSuite.setParallel(java.lang.String)'
> at
> org.apache.maven.surefire.testng.conf.TestNGMapConfigurator.configure(TestNGMapConfigurator.java:71)
> at
> org.apache.maven.surefire.testng.conf.TestNG510Configurator.configure(TestNG510Configurator.java:40)
> at
> org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:111)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeSingleClass(TestNGDirectoryTestSuite.java:112)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:99)
> at
> org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:145)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1890) Not compatible with TestNG 7.4.0
[
https://issues.apache.org/jira/browse/SUREFIRE-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519246#comment-17519246
]
Scott Babcock commented on SUREFIRE-1890:
-
This is a blocker... My POM doesn't specify at all, and it defaults
to "none", which gets rejected by this code as invalid. I'm working on a pull
request now, hoping to submit this later today.
> Not compatible with TestNG 7.4.0
>
>
> Key: SUREFIRE-1890
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1890
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 3.0.0-M5
>Reporter: Joe Barnett
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
>
> TestNG 7.4.0 removed the deprecated method
> {{org.testng.xml.XmlSuite.setParallel(java.lang.String)}}. Trying to run
> tests with parallelism set results in:
> {code:java}
> java.lang.NoSuchMethodError: 'void
> org.testng.xml.XmlSuite.setParallel(java.lang.String)'
> at
> org.apache.maven.surefire.testng.conf.TestNGMapConfigurator.configure(TestNGMapConfigurator.java:71)
> at
> org.apache.maven.surefire.testng.conf.TestNG510Configurator.configure(TestNG510Configurator.java:40)
> at
> org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:111)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeSingleClass(TestNGDirectoryTestSuite.java:112)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:99)
> at
> org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:145)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1890) Not compatible with TestNG 7.4.0
[
https://issues.apache.org/jira/browse/SUREFIRE-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519243#comment-17519243
]
Tibor Digana commented on SUREFIRE-1890:
[~scoba] The values should be checked according to what is real in TestNG, see
https://github.com/cbeust/testng/blob/master/testng-core-api/src/main/java/org/testng/xml/XmlSuite.java
{code:java}
public enum ParallelMode {
TESTS("tests", false),
METHODS("methods"),
CLASSES("classes"),
INSTANCES("instances"),
NONE("none", false);
{code}
but I think this is not a blocker because the user can avoid using
for NONE.
You can open a PR with the fix on GH.
> Not compatible with TestNG 7.4.0
>
>
> Key: SUREFIRE-1890
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1890
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 3.0.0-M5
>Reporter: Joe Barnett
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
>
> TestNG 7.4.0 removed the deprecated method
> {{org.testng.xml.XmlSuite.setParallel(java.lang.String)}}. Trying to run
> tests with parallelism set results in:
> {code:java}
> java.lang.NoSuchMethodError: 'void
> org.testng.xml.XmlSuite.setParallel(java.lang.String)'
> at
> org.apache.maven.surefire.testng.conf.TestNGMapConfigurator.configure(TestNGMapConfigurator.java:71)
> at
> org.apache.maven.surefire.testng.conf.TestNG510Configurator.configure(TestNG510Configurator.java:40)
> at
> org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:111)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeSingleClass(TestNGDirectoryTestSuite.java:112)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:99)
> at
> org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:145)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-wrapper] speedlog opened a new pull request, #38: (doc) Fixing doc about installing mvnDebug-scripts
speedlog opened a new pull request, #38: URL: https://github.com/apache/maven-wrapper/pull/38 Adaptation of documentation to current behavior: https://github.com/apache/maven-wrapper/blob/master/maven-wrapper-plugin/src/main/java/org/apache/maven/plugins/wrapper/WrapperMojo.java#L98 -- 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] (SUREFIRE-1890) Not compatible with TestNG 7.4.0
[
https://issues.apache.org/jira/browse/SUREFIRE-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519202#comment-17519202
]
Scott Babcock edited comment on SUREFIRE-1890 at 4/7/22 10:47 PM:
--
The implementation of this fix breaks the ability to run tests sequentially:
{code:java}
[ERROR] There was an error in the forked process
[ERROR] Unsupported TestNG parallel setting: none ( only METHODS or CLASSES
supported )
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There was
an error in the forked process
[ERROR] Unsupported TestNG parallel setting: none ( only METHODS or CLASSES
supported )
{code}
The default value for an unspecified setting is "none", not {{null}}.
was (Author: scoba):
The implementation of this fix breaks the ability to run tests sequentially:
{code:java}
[ERROR] There was an error in the forked process
[ERROR] Unsupported TestNG parallel setting: none ( only METHODS or CLASSES
supported )
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There was
an error in the forked process
[ERROR] Unsupported TestNG parallel setting: none ( only METHODS or CLASSES
supported ) {code}
> Not compatible with TestNG 7.4.0
>
>
> Key: SUREFIRE-1890
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1890
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 3.0.0-M5
>Reporter: Joe Barnett
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
>
> TestNG 7.4.0 removed the deprecated method
> {{org.testng.xml.XmlSuite.setParallel(java.lang.String)}}. Trying to run
> tests with parallelism set results in:
> {code:java}
> java.lang.NoSuchMethodError: 'void
> org.testng.xml.XmlSuite.setParallel(java.lang.String)'
> at
> org.apache.maven.surefire.testng.conf.TestNGMapConfigurator.configure(TestNGMapConfigurator.java:71)
> at
> org.apache.maven.surefire.testng.conf.TestNG510Configurator.configure(TestNG510Configurator.java:40)
> at
> org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:111)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeSingleClass(TestNGDirectoryTestSuite.java:112)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:99)
> at
> org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:145)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1890) Not compatible with TestNG 7.4.0
[
https://issues.apache.org/jira/browse/SUREFIRE-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519202#comment-17519202
]
Scott Babcock commented on SUREFIRE-1890:
-
The implementation of this fix breaks the ability to run tests sequentially:
{code:java}
[ERROR] There was an error in the forked process
[ERROR] Unsupported TestNG parallel setting: none ( only METHODS or CLASSES
supported )
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There was
an error in the forked process
[ERROR] Unsupported TestNG parallel setting: none ( only METHODS or CLASSES
supported ) {code}
> Not compatible with TestNG 7.4.0
>
>
> Key: SUREFIRE-1890
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1890
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 3.0.0-M5
>Reporter: Joe Barnett
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
>
> TestNG 7.4.0 removed the deprecated method
> {{org.testng.xml.XmlSuite.setParallel(java.lang.String)}}. Trying to run
> tests with parallelism set results in:
> {code:java}
> java.lang.NoSuchMethodError: 'void
> org.testng.xml.XmlSuite.setParallel(java.lang.String)'
> at
> org.apache.maven.surefire.testng.conf.TestNGMapConfigurator.configure(TestNGMapConfigurator.java:71)
> at
> org.apache.maven.surefire.testng.conf.TestNG510Configurator.configure(TestNG510Configurator.java:40)
> at
> org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:111)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeSingleClass(TestNGDirectoryTestSuite.java:112)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:99)
> at
> org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:145)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] (MPMD-303) Configuration is ignored
[ https://issues.apache.org/jira/browse/MPMD-303 ]
Seth Wilcox deleted comment on MPMD-303:
--
was (Author: laoseth):
To clarify, this occurs when it is part of a larger build as well as when you
run directly from the command line. After a lot of debugging, i was able to
verify that the sourceEncoding attribute was the only config that was never
being read, and after the patch in
[https://github.com/apache/maven-pmd-plugin/pull/64] was applied locally, files
with UTF-8 no longer caused stacks in analysis. I think there is a good chance
this issue can be hidden, as it is defaulting to the system default encoding
now, which especially in the nix world is UTF-8 anyways.
> Configuration is ignored
>
>
> Key: MPMD-303
> URL: https://issues.apache.org/jira/browse/MPMD-303
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.13.0
>Reporter: Luigi Berrettini
>Priority: Critical
> Attachments: poc-mvn-pmd-plugin.zip
>
>
> I configured the reporting plugin this way:
> {noformat}
>
> org.apache.maven.plugins
> maven-pmd-plugin
> 3.13.0
>
>
> /category/java/bestpractices.xml
> /category/java/errorprone.xml
> /category/java/security.xml
> /category/java/performance.xml
> /category/java/multithreading.xml
> /category/java/design.xml
> /category/java/codestyle.xml
> /category/java/documentation.xml
>
> true
> 1
> 1
> true
> true
> true
> false
> false
> false
>
> {noformat}
>
> When I run *_mvn site_* or *_mvn pmd:pmd_* no output is display on the
> console and the default ruleset is used since only
> *_target\pmd\rulesets\maven-pmd-plugin-default.xml_* is generated.
> Looking at the code on GitHub I see the repo contains only the default
> ruleset.
>
> Moreover the build plugin configuration does not support rulesets which would
> be a nice to have.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MPMD-303) Configuration is ignored
[
https://issues.apache.org/jira/browse/MPMD-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519192#comment-17519192
]
Seth Wilcox commented on MPMD-303:
--
To clarify, this occurs when it is part of a larger build as well as when you
run directly from the command line. After a lot of debugging, i was able to
verify that the sourceEncoding attribute was the only config that was never
being read, and after the patch in
[https://github.com/apache/maven-pmd-plugin/pull/64] was applied locally, files
with UTF-8 no longer caused stacks in analysis. I think there is a good chance
this issue can be hidden, as it is defaulting to the system default encoding
now, which especially in the nix world is UTF-8 anyways.
> Configuration is ignored
>
>
> Key: MPMD-303
> URL: https://issues.apache.org/jira/browse/MPMD-303
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.13.0
>Reporter: Luigi Berrettini
>Priority: Critical
> Attachments: poc-mvn-pmd-plugin.zip
>
>
> I configured the reporting plugin this way:
> {noformat}
>
> org.apache.maven.plugins
> maven-pmd-plugin
> 3.13.0
>
>
> /category/java/bestpractices.xml
> /category/java/errorprone.xml
> /category/java/security.xml
> /category/java/performance.xml
> /category/java/multithreading.xml
> /category/java/design.xml
> /category/java/codestyle.xml
> /category/java/documentation.xml
>
> true
> 1
> 1
> true
> true
> true
> false
> false
> false
>
> {noformat}
>
> When I run *_mvn site_* or *_mvn pmd:pmd_* no output is display on the
> console and the default ruleset is used since only
> *_target\pmd\rulesets\maven-pmd-plugin-default.xml_* is generated.
> Looking at the code on GitHub I see the repo contains only the default
> ruleset.
>
> Moreover the build plugin configuration does not support rulesets which would
> be a nice to have.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] chalmagr opened a new pull request, #516: Test Reports Inconsistencies with Parameterized and junit4
chalmagr opened a new pull request, #516: URL: https://github.com/apache/maven-surefire/pull/516 Changing the run listener to use the nameText value (for parameterized scenarios) to prevent invalid flake test reports (see https://github.com/chalmagr/surefire-flaky-report) I am unable to run some tests for surefire-grouper / surefire-its: ``` Caused by: java.lang.ClassNotFoundException: org.apache.maven.shadefire.surefire.booter.ForkedBooter ``` Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SUREFIRE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean install`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7433) [REGRESSION] Multiple maven instances working on same source tree can lock each other
[
https://issues.apache.org/jira/browse/MNG-7433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519165#comment-17519165
]
Dan Tran commented on MNG-7433:
---
here is a brief just to visualize the issue and its steps
{code:java}
10:59:16 [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
xxx-mvnrepo ---
10:59:16 [INFO]
10:59:16 [INFO] --< com.xxx.xxx.xxx:sonar-analysis
>--
10:59:16 [INFO] Building sonar-analysis 19.11.0-1-SNAPSHOT
[538/540]
10:59:16 [INFO] [ pom
]-
10:59:16 [INFO]
10:59:16 [INFO] ---< com.xxx.xxx.xxx.installer:xxx-puppet-config
>
10:59:16 [INFO] Building xxx-puppet-config 19.11.0-1-SNAPSHOT
[539/540]
10:59:16 [INFO] [ rpm
]-
10:59:16 [INFO]
10:59:16 [INFO] --- maven-enforcer-plugin:1.4.1:enforce (default) @
sonar-analysis ---
10:59:16 [INFO]
10:59:16 [INFO] --- jacoco-maven-plugin:0.8.7:prepare-agent (jacoco-all) @
sonar-analysis ---
10:59:16 [INFO] argLine set to
-javaagent:/space/jenkins/workspace/xxx_xxx_xxx_PR-4236/.repository/org/jacoco/org.jacoco.agent/0.8.7/org.jacoco.agent-0.8.7-runtime.jar=destfile=/space/jenkins/workspace/xxx_xxx_xxx_PR-4236/sonar/target/jacoco.exec
10:59:16 [INFO]
10:59:16 [INFO] --- flatten-maven-plugin:1.2.7:flatten (flatten) @
sonar-analysis ---
10:59:16 [INFO] Generating flattened POM of project
com.xxx.xxx.xxx:sonar-analysis:pom:19.11.0-1-SNAPSHOT...
10:59:16 [INFO]
10:59:16 [INFO] --- jacoco-maven-plugin:0.8.7:report (jacoco-all) @
sonar-analysis ---
10:59:16 [INFO] Skipping JaCoCo execution due to missing execution data file.
10:59:20 [INFO]
10:59:20 [INFO] --- maven-enforcer-plugin:1.4.1:enforce (default) @
xxx-puppet-config ---
10:59:20 [INFO]
10:59:20 [INFO] --- mdev-maven-plugin:1.6.3:sonar
(quiet-sonar-scan-by-default) @ sonar-analysis ---
10:59:20 [INFO] Executing: /bin/sh -c cd
'/space/jenkins/workspace/xxx_xxx_xxx_PR-4236' &&
'/xxx/build/.m2/wrapper/dists/apache-maven-3.8.5-bin/5sf9ufumnhp6odg6f4svjl54q1/apache-maven-3.8.5/bin/mvn'
'-ntp' 'sonar:sonar' '-Dsonar.pullrequest.key=4236'
'-Dsonar.pullrequest.branch=personal/trand8/maven-3.8.5-2'
'-Dsonar.pullrequest.base=master' '--quiet' '-P!sonar' '-s'
'/tmp/settings43566726mvn'. Working directory:
/space/jenkins/workspace/xxx_xxx_xxx_PR-4236
{code}
it shows - after xxx-mvnrepos is done, 2 module then run in parallel:
sonar-analysis and xxx-puppet-config. The xxx-puppet-config stalls after
sonar-analisys spins another maven instant to run sonar:sonar
> [REGRESSION] Multiple maven instances working on same source tree can lock
> each other
> -
>
> Key: MNG-7433
> URL: https://issues.apache.org/jira/browse/MNG-7433
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.5
>Reporter: Dan Tran
>Priority: Major
>
> I have a large multi modules java maven build where:
> * phase 1 - basic build + unit tests + jacoco - 40 min
> * phase 2 - sonar:sonar 20 min
> * phase 3 - final packaging and basic smoke-test - 20 min
> To take advantage of Maven multi-threaded build, during the reactor build,
> one of our maven module spins another instance of Maven to run sonar:sonar
> goal right after the basic build is done.
> This means our phase 2 and phase 3 run in parallel sharing the same source
> tree, same local maven repo (where sonar:sonar should have all needed
> dependencies at the share local maven repo to run its task)
> With maven-3.8.5, parallelization is no longer possible, phase 3 is blocked
> until phase 2 is done.
> I am able to trace it to https://github.com/apache/maven/pull/628 where the
> locking started the happen
> How does the lock mechanic work? there must be a local file where both Maven
> instances are watching each other. Is there an option to disable this lock?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MDEP-791) Non-test scoped and transitive dependencies in compile scope
[
https://issues.apache.org/jira/browse/MDEP-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519156#comment-17519156
]
Steven Schlansker commented on MDEP-791:
Thank you for the workaround :)
> Non-test scoped and transitive dependencies in compile scope
>
>
> Key: MDEP-791
> URL: https://issues.apache.org/jira/browse/MDEP-791
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Slawomir Jaranowski
>Priority: Critical
> Attachments: MDEP-791.zip
>
>
> When we use some dependency in test classes which is not used in production
> code but is required as transitive dependency for other used in production
> code - such dependency should not be included in {*}{{Non-test scoped}}{*}.
> Example:
> * test code use {{ObjectCodec}} from {{jackson-core}}
> * production code use only {{ObjectMapper}} from {{jackson-databind}}
> * production code don't use any classes from {{jackson-core}}
> {{jackson-core}} is needed by {{jackson-databind}} and must by in compile
> scope so should not be reported as {{Non-test scoped}}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] Tibor17 commented on a diff in pull request #505: [SUREFIRE-2055] Always show random seed
Tibor17 commented on code in PR #505:
URL: https://github.com/apache/maven-surefire/pull/505#discussion_r844543780
##
surefire-its/src/test/java/org/apache/maven/surefire/its/RunOrderIT.java:
##
@@ -97,7 +97,17 @@ public void testRandomJUnit4SameSeed()
}
}
}
-
+
+@Test
+public void testRandomJUnit4PrintSeed()
+{
+long seed = 0L;
+OutputValidator validator = executeWithRandomOrder( "junit4", seed );
+validator.verifyTextInLog( "To reproduce ordering use flag" );
+validator = executeWithRandomOrder( "junit4" );
+validator.verifyTextInLog( "To reproduce ordering use flag" );
Review Comment:
@delanym I made `RunOrderParameters` immutable because the contributor did
not implement it right and the setter was not necessary. Pls rebase your branch
on `origin/master`. You should exclude the fallback value `System.nanoTime()`
in the `DefaultRunOrderCalculator` constructor and use it only in MOJO. It does
not make sense to do one thing twice with the seed.
Finally `this.random = new Random( runOrderRandomSeed == null ?
System.nanoTime() : runOrderRandomSeed );` would become `random =
runOrderRandomSeed == null ? null : new Random( runOrderRandomSeed );`.
--
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-7316) MavenProject.getAttachedArtifacts() regression with 3.8.1
[
https://issues.apache.org/jira/browse/MNG-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519128#comment-17519128
]
Gary D. Gregory commented on MNG-7316:
--
Hi [~chtompki] Any news?
> MavenProject.getAttachedArtifacts() regression with 3.8.1
> -
>
> Key: MNG-7316
> URL: https://issues.apache.org/jira/browse/MNG-7316
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.2, 3.8.3
>Reporter: Gary D. Gregory
>Priority: Critical
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> The method {{MavenProject.getAttachedArtifacts()}} as of 3.8.2 breaks
> releasing components for us at Apache Commons using our Maven Release plugin
> because the list returned is now immutable, we now get an exception when
> calling {{remove()}} on the collection returned by the API; see
> [https://github.com/apache/commons-release-plugin/blob/master/src/main/java/org/apache/commons/release/plugin/mojos/CommonsDistributionDetachmentMojo.java#L137]
> This worked fine in 3.8.1, may you please change it back for 3.8.4?
> We cannot use Maven 3.8.2 and 3.8.3 to release our components.
> ([~michael-o]: Ironically, I discovered this trying to create a release
> candidate for Apache Commons CLI.)
> The exception in 3.8.3:
> {quote}Caused by: java.lang.UnsupportedOperationException
> at java.util.Collections$UnmodifiableCollection.remove
> (Collections.java:1060)
> at
> org.apache.commons.release.plugin.mojos.CommonsDistributionDetachmentMojo.execute
> (CommonsDistributionDetachmentMojo.java:136)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-828) log all mojo parameters and their populated values in debug mode
[ https://issues.apache.org/jira/browse/MNG-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519121#comment-17519121 ] Hudson commented on MNG-828: Build unstable in Jenkins: Maven » Maven TLP » maven » maven-3.8.x-fix-its-jdk1.7 #3 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.8.x-fix-its-jdk1.7/3/ > log all mojo parameters and their populated values in debug mode > > > Key: MNG-828 > URL: https://issues.apache.org/jira/browse/MNG-828 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Reporter: Brett Porter >Assignee: Brett Porter >Priority: Minor > Fix For: 2.0 (RC) > > > when we have this, we should remove the debugging code from plugins such as > ear that do this manually. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MRESOLVER-248) Make DF and BF collector implementations coexist
[
https://issues.apache.org/jira/browse/MRESOLVER-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRESOLVER-248:
-
Summary: Make DF and BF collector implementations coexist (was: Make DF
and BF collector implementations coexists)
> Make DF and BF collector implementations coexist
>
>
> Key: MRESOLVER-248
> URL: https://issues.apache.org/jira/browse/MRESOLVER-248
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 1.8.0
>
>
> There is ongoing work to fundamentally change {{DependencyCollector}}
> implementation in resolver.
> Resolver was from beginning building dependency graph by doing "depth first"
> (df) approach, and was downloading POMs sequentially during collection.
> With work happing under MRESOLVER-240, MRESOLVER-247 and MRESOLVER-7,
> collector is altered: is doing now "breadth first" (bf), implements
> skip-reconcile and will have parallel POM download implemented, and maybe
> even more (like inter collection cache?).
> Still, IMHO letting both (original "df" and new "bf") coexists is technically
> simple, and would allow us not only simpler comparison of the performance of
> the two, but there is a possibility that there will be no "one size fit all"
> solution, so having both knives in drawer is just a win-win. Also, this way
> we do have a "baseline" to compare with easily: the "df" (original) collector
> vs "bf" collector.
> Ultimately, we MAY prove superiority of one over another, essentially leaving
> only one collector implementation, as in that case this issue (and the
> "coexistence indirection") should be just removed, and not enlist it in
> release notes of upcoming 1.8.0 version.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MCOMPILER-490) Compilation warning when using BOM dependency in pom.xml
[
https://issues.apache.org/jira/browse/MCOMPILER-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MCOMPILER-490.
Resolution: Information Provided
> Compilation warning when using BOM dependency in pom.xml
>
>
> Key: MCOMPILER-490
> URL: https://issues.apache.org/jira/browse/MCOMPILER-490
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.9.0, 3.10.0, 3.10.1
>Reporter: Thomas Smith
>Priority: Minor
>
> When using a BOM dependency in pom.xml with the {{-Xlint:all}} compiler
> argument, maven-compiler-plugin will show the following compiler warning:
> {code:none}
> [WARNING] [path] Unexpected file on path: {code}
> This occurs in maven-compiler-plugin 3.9.0 and later (starting with [this
> commit|https://github.com/apache/maven-compiler-plugin/commit/f17b9e2d9d0c89b76fb5e8f980529534c0c109f6#diff-770d75eb3f1634cb819ccb05b6462d37376807e2170d5b9f415992fd0746f12c]).
> It seems to be happening because maven-compiler-plugin is including .pom
> files for these dependencies in the {{{}$CLASSPATH{}}}.
> Here is a pom.xml that reproduces the issue:
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> com.example
> main
> 1.0
> main
>
> UTF-8
> 17
>
>
>
> com.fasterxml.jackson
> jackson-bom
> 2.13.2.1
> pom
>
>
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.9.0
>
> true
>
> -Xlint:all
>
> true
>
>
>
>
>
> {code}
> Here's my output of {{{}mvn --version{}}}:
> {code:none}
> Apache Maven 3.8.3 (ff8e977a158738155dc465c6a97ffaf31982d739)
> Maven home: /Users/***/.asdf/installs/maven/3.8.3
> Java version: 17.0.1, vendor: Oracle Corporation, runtime:
> /Users/***/.asdf/installs/java/openjdk-17.0.1
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "12.3.1", arch: "x86_64", family: "mac"
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MDEP-791) Non-test scoped and transitive dependencies in compile scope
[
https://issues.apache.org/jira/browse/MDEP-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519107#comment-17519107
]
Slawomir Jaranowski commented on MDEP-791:
--
Version 3.3.0 support JDK 17
> Non-test scoped and transitive dependencies in compile scope
>
>
> Key: MDEP-791
> URL: https://issues.apache.org/jira/browse/MDEP-791
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Slawomir Jaranowski
>Priority: Critical
> Attachments: MDEP-791.zip
>
>
> When we use some dependency in test classes which is not used in production
> code but is required as transitive dependency for other used in production
> code - such dependency should not be included in {*}{{Non-test scoped}}{*}.
> Example:
> * test code use {{ObjectCodec}} from {{jackson-core}}
> * production code use only {{ObjectMapper}} from {{jackson-databind}}
> * production code don't use any classes from {{jackson-core}}
> {{jackson-core}} is needed by {{jackson-databind}} and must by in compile
> scope so should not be reported as {{Non-test scoped}}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MDEP-791) Non-test scoped and transitive dependencies in compile scope
[
https://issues.apache.org/jira/browse/MDEP-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519104#comment-17519104
]
Slawomir Jaranowski commented on MDEP-791:
--
There is workaround from version 3.3.0
You can add
{code}
*
{code}
with such configuration all checks for problematics {{NonTestScoped}} will be
skipped.
https://maven.apache.org/plugins/maven-dependency-plugin/examples/exclude-dependencies-from-dependency-analysis.html
> Non-test scoped and transitive dependencies in compile scope
>
>
> Key: MDEP-791
> URL: https://issues.apache.org/jira/browse/MDEP-791
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Slawomir Jaranowski
>Priority: Critical
> Attachments: MDEP-791.zip
>
>
> When we use some dependency in test classes which is not used in production
> code but is required as transitive dependency for other used in production
> code - such dependency should not be included in {*}{{Non-test scoped}}{*}.
> Example:
> * test code use {{ObjectCodec}} from {{jackson-core}}
> * production code use only {{ObjectMapper}} from {{jackson-databind}}
> * production code don't use any classes from {{jackson-core}}
> {{jackson-core}} is needed by {{jackson-databind}} and must by in compile
> scope so should not be reported as {{Non-test scoped}}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-828) log all mojo parameters and their populated values in debug mode
[ https://issues.apache.org/jira/browse/MNG-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519099#comment-17519099 ] Hudson commented on MNG-828: Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-7451 #2 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7451/2/ > log all mojo parameters and their populated values in debug mode > > > Key: MNG-828 > URL: https://issues.apache.org/jira/browse/MNG-828 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Reporter: Brett Porter >Assignee: Brett Porter >Priority: Minor > Fix For: 2.0 (RC) > > > when we have this, we should remove the debugging code from plugins such as > ear that do this manually. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2004) Empty report for single-module project with 'aggregate=true'
[
https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519089#comment-17519089
]
Tibor Digana commented on SUREFIRE-2004:
[~kriegaex]
This issue has nothing to do with long development releases.
If the fix not clear, then it is better not to touch the code, otherwise I
break it, and if I break it then the problem is mine and very hard to argue the
next fix. So this issue required some clarification. The problem with M6 was
that we concentrated only on issues reported by the users, then came covid and
I became more less idle in OSS and more active in legal affairs in advocacy of
some people. Today the situation is different because we have got Slawomir, so
we are two active developers. The highest priority is to catch up the plan of
milestones where our tasks would lead to break backwards compatibility (first
inside, then outside in config params).
> Empty report for single-module project with 'aggregate=true'
>
>
> Key: SUREFIRE-2004
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2004
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.4, 3.0.0-M5
>Reporter: Alexander Kriegisch
>Priority: Major
> Fix For: waiting-for-apache-feedback
>
>
> Using either {{-Daggregate=true}} on CLI or {{true}}
> in the plugin configuration leads to an empty report (i.e. zero tests
> reported) when e.g. executing
> {code:none}
> mvn -Dmaven.test.failure.ignore=true -Daggregate=true clean verify
> surefire-report:report-only
> {code}
> in the context of a single-module project. As soon as I make the root module
> pom-packaged and move the tests to into a child module, the aggregate report
> works.
> FYI, if I do not define the plugin and its version in my POM at all, the
> default version 2.4 used by Maven on my workstation has the same problem, so
> this does not seem to be a 3.0.0-M5 issue only.
>
> Background info about how and why I actually stumbled across this problem: I
> have an OSS multi-module project with lots of expensive UI tests. The full
> build can take 2.5 hours. I wanted to test a few CLI settings before creating
> an additional GitHub CI build workflow which can be run on demand and always
> runs all tests in all modules (ignoring errors and failures), no matter what.
> In the end, it is supposed to create a single-file aggregate HTML report
> which can easily be attached to the build and later is available for
> download, if the user so chooses in order to analyse failing tests
> comfortable and without having to scroll through build logs. You get the
> picture, I guess. In the original project, there is a pom-packaged root POM,
> so the problem described in this issue does not occur there. I simply created
> a single-module dummy project in order to verify the effect of certain build
> options quickly and not having to wait for the slow original build to finish.
> Eventually, I noticed the issue described above.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MDEP-791) Non-test scoped and transitive dependencies in compile scope
[
https://issues.apache.org/jira/browse/MDEP-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519088#comment-17519088
]
Steven Schlansker commented on MDEP-791:
I appreciate that this is ultimately a bug in Maven Core, however a fix there
is likely to take a long time (Maven 4?) and in the meantime users cannot
target any new JDK 17+.
Should we consider releasing artifacts that support JDK 17+ source level, but
use the old (incorrect) checker rules? At this point we are waiting for a very
long time with no progress. I agree it's a stop-gap but the whole community
that wants to target latest JDK is stuck on this set of issues at this point.
Fixing the Maven bug with dependency resolution is a great outcome, but it
should be implemented bottom-up (first fix core, then improve checker rules)
rather than the other way around (improve checker rules, break, wait
indefinitely on core...)
> Non-test scoped and transitive dependencies in compile scope
>
>
> Key: MDEP-791
> URL: https://issues.apache.org/jira/browse/MDEP-791
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Slawomir Jaranowski
>Priority: Critical
> Attachments: MDEP-791.zip
>
>
> When we use some dependency in test classes which is not used in production
> code but is required as transitive dependency for other used in production
> code - such dependency should not be included in {*}{{Non-test scoped}}{*}.
> Example:
> * test code use {{ObjectCodec}} from {{jackson-core}}
> * production code use only {{ObjectMapper}} from {{jackson-databind}}
> * production code don't use any classes from {{jackson-core}}
> {{jackson-core}} is needed by {{jackson-databind}} and must by in compile
> scope so should not be reported as {{Non-test scoped}}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-pmd-plugin] laoseth opened a new pull request, #64: MPMD-334 - Source Encoding parameter is ignored
laoseth opened a new pull request, #64: URL: https://github.com/apache/maven-pmd-plugin/pull/64 Following this checklist to help us incorporate your contribution quickly and easily: - [X ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MPMD-334) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [X ] Each commit in the pull request should have a meaningful subject line and body. - [X ] Format the pull request title like `[MPMD-XXX] - Subject of the JIRA Ticket`, where you replace `MPMD-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ X] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [X ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [X ] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [X ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MPMD-334) Source Encoding parameter is ignored
Seth Wilcox created MPMD-334: Summary: Source Encoding parameter is ignored Key: MPMD-334 URL: https://issues.apache.org/jira/browse/MPMD-334 Project: Maven PMD Plugin Issue Type: Bug Reporter: Seth Wilcox The sourceEncoding parameter is not passed from the PMDRequest object into the PMD configuration. This cause PMD to default to the system's default encoding. This was discovered due to inconsistant behavior with UTF-8 chars from windows to linux. I verified it is the only property in PmdRequest not being referenced -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MCOMPILER-490) Compilation warning when using BOM dependency in pom.xml
[
https://issues.apache.org/jira/browse/MCOMPILER-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519065#comment-17519065
]
Thomas Smith commented on MCOMPILER-490:
Thanks for the link. Unfortunately I don't see a way for me to change this
ticket's status, but feel free to close it if you are able.
> Compilation warning when using BOM dependency in pom.xml
>
>
> Key: MCOMPILER-490
> URL: https://issues.apache.org/jira/browse/MCOMPILER-490
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.9.0, 3.10.0, 3.10.1
>Reporter: Thomas Smith
>Priority: Minor
>
> When using a BOM dependency in pom.xml with the {{-Xlint:all}} compiler
> argument, maven-compiler-plugin will show the following compiler warning:
> {code:none}
> [WARNING] [path] Unexpected file on path: {code}
> This occurs in maven-compiler-plugin 3.9.0 and later (starting with [this
> commit|https://github.com/apache/maven-compiler-plugin/commit/f17b9e2d9d0c89b76fb5e8f980529534c0c109f6#diff-770d75eb3f1634cb819ccb05b6462d37376807e2170d5b9f415992fd0746f12c]).
> It seems to be happening because maven-compiler-plugin is including .pom
> files for these dependencies in the {{{}$CLASSPATH{}}}.
> Here is a pom.xml that reproduces the issue:
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> com.example
> main
> 1.0
> main
>
> UTF-8
> 17
>
>
>
> com.fasterxml.jackson
> jackson-bom
> 2.13.2.1
> pom
>
>
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.9.0
>
> true
>
> -Xlint:all
>
> true
>
>
>
>
>
> {code}
> Here's my output of {{{}mvn --version{}}}:
> {code:none}
> Apache Maven 3.8.3 (ff8e977a158738155dc465c6a97ffaf31982d739)
> Maven home: /Users/***/.asdf/installs/maven/3.8.3
> Java version: 17.0.1, vendor: Oracle Corporation, runtime:
> /Users/***/.asdf/installs/java/openjdk-17.0.1
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "12.3.1", arch: "x86_64", family: "mac"
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] Tibor17 commented on pull request #339: [SUREFIRE-1890] Support TestNG 7.4.0
Tibor17 commented on PR #339: URL: https://github.com/apache/maven-surefire/pull/339#issuecomment-1092029116 @dankirkd I can confirm that the Jira issue [SUREFIRE-1890](https://issues.apache.org/jira/browse/SUREFIRE-1890) was fixed. If this was the only compatibility issue, the TestNG should work properly. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MCOMPILER-490) Compilation warning when using BOM dependency in pom.xml
[
https://issues.apache.org/jira/browse/MCOMPILER-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519062#comment-17519062
]
Piotr Zygielo commented on MCOMPILER-490:
-
[https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms]
{quote}Other projects that wish to use the library should import this POM into
the dependencyManagement section of their POM.
...
the library can now be used in another project without having to specify the
dependent project's versions.
{quote}
> Compilation warning when using BOM dependency in pom.xml
>
>
> Key: MCOMPILER-490
> URL: https://issues.apache.org/jira/browse/MCOMPILER-490
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.9.0, 3.10.0, 3.10.1
>Reporter: Thomas Smith
>Priority: Minor
>
> When using a BOM dependency in pom.xml with the {{-Xlint:all}} compiler
> argument, maven-compiler-plugin will show the following compiler warning:
> {code:none}
> [WARNING] [path] Unexpected file on path: {code}
> This occurs in maven-compiler-plugin 3.9.0 and later (starting with [this
> commit|https://github.com/apache/maven-compiler-plugin/commit/f17b9e2d9d0c89b76fb5e8f980529534c0c109f6#diff-770d75eb3f1634cb819ccb05b6462d37376807e2170d5b9f415992fd0746f12c]).
> It seems to be happening because maven-compiler-plugin is including .pom
> files for these dependencies in the {{{}$CLASSPATH{}}}.
> Here is a pom.xml that reproduces the issue:
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> com.example
> main
> 1.0
> main
>
> UTF-8
> 17
>
>
>
> com.fasterxml.jackson
> jackson-bom
> 2.13.2.1
> pom
>
>
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.9.0
>
> true
>
> -Xlint:all
>
> true
>
>
>
>
>
> {code}
> Here's my output of {{{}mvn --version{}}}:
> {code:none}
> Apache Maven 3.8.3 (ff8e977a158738155dc465c6a97ffaf31982d739)
> Maven home: /Users/***/.asdf/installs/maven/3.8.3
> Java version: 17.0.1, vendor: Oracle Corporation, runtime:
> /Users/***/.asdf/installs/java/openjdk-17.0.1
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "12.3.1", arch: "x86_64", family: "mac"
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MCOMPILER-490) Compilation warning when using BOM dependency in pom.xml
[
https://issues.apache.org/jira/browse/MCOMPILER-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519061#comment-17519061
]
Thomas Smith commented on MCOMPILER-490:
To answer my own question, it looks like BOM dependencies should be included in
the {{dependencyManagement}} section of pom.xml, like so:
{code:xml}
com.fasterxml.jackson
jackson-bom
2.13.2.1
pom
import
{code}
Since this issue was my mistake, I'll close it, although it would be nice if
there was a warning or error more directly pointing out the problem with
pom.xml files like this one.
> Compilation warning when using BOM dependency in pom.xml
>
>
> Key: MCOMPILER-490
> URL: https://issues.apache.org/jira/browse/MCOMPILER-490
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.9.0, 3.10.0, 3.10.1
>Reporter: Thomas Smith
>Priority: Minor
>
> When using a BOM dependency in pom.xml with the {{-Xlint:all}} compiler
> argument, maven-compiler-plugin will show the following compiler warning:
> {code:none}
> [WARNING] [path] Unexpected file on path: {code}
> This occurs in maven-compiler-plugin 3.9.0 and later (starting with [this
> commit|https://github.com/apache/maven-compiler-plugin/commit/f17b9e2d9d0c89b76fb5e8f980529534c0c109f6#diff-770d75eb3f1634cb819ccb05b6462d37376807e2170d5b9f415992fd0746f12c]).
> It seems to be happening because maven-compiler-plugin is including .pom
> files for these dependencies in the {{{}$CLASSPATH{}}}.
> Here is a pom.xml that reproduces the issue:
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> com.example
> main
> 1.0
> main
>
> UTF-8
> 17
>
>
>
> com.fasterxml.jackson
> jackson-bom
> 2.13.2.1
> pom
>
>
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.9.0
>
> true
>
> -Xlint:all
>
> true
>
>
>
>
>
> {code}
> Here's my output of {{{}mvn --version{}}}:
> {code:none}
> Apache Maven 3.8.3 (ff8e977a158738155dc465c6a97ffaf31982d739)
> Maven home: /Users/***/.asdf/installs/maven/3.8.3
> Java version: 17.0.1, vendor: Oracle Corporation, runtime:
> /Users/***/.asdf/installs/java/openjdk-17.0.1
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "12.3.1", arch: "x86_64", family: "mac"
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-compiler-plugin] rmannibucau commented on pull request #88: [MCOMPILER-205] Add a boolean to generate missing package-info classes by default
rmannibucau commented on PR #88: URL: https://github.com/apache/maven-compiler-plugin/pull/88#issuecomment-1092016510 +1 it is also true on plain JVM and EE containers where it has side effects (even if some can be silently recovered) so agree default should change to be backward compatible in next release. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MCOMPILER-490) Compilation warning when using BOM dependency in pom.xml
[
https://issues.apache.org/jira/browse/MCOMPILER-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519049#comment-17519049
]
Thomas Smith commented on MCOMPILER-490:
What is the correct way to use the BOM?
> Compilation warning when using BOM dependency in pom.xml
>
>
> Key: MCOMPILER-490
> URL: https://issues.apache.org/jira/browse/MCOMPILER-490
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.9.0, 3.10.0, 3.10.1
>Reporter: Thomas Smith
>Priority: Minor
>
> When using a BOM dependency in pom.xml with the {{-Xlint:all}} compiler
> argument, maven-compiler-plugin will show the following compiler warning:
> {code:none}
> [WARNING] [path] Unexpected file on path: {code}
> This occurs in maven-compiler-plugin 3.9.0 and later (starting with [this
> commit|https://github.com/apache/maven-compiler-plugin/commit/f17b9e2d9d0c89b76fb5e8f980529534c0c109f6#diff-770d75eb3f1634cb819ccb05b6462d37376807e2170d5b9f415992fd0746f12c]).
> It seems to be happening because maven-compiler-plugin is including .pom
> files for these dependencies in the {{{}$CLASSPATH{}}}.
> Here is a pom.xml that reproduces the issue:
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> com.example
> main
> 1.0
> main
>
> UTF-8
> 17
>
>
>
> com.fasterxml.jackson
> jackson-bom
> 2.13.2.1
> pom
>
>
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.9.0
>
> true
>
> -Xlint:all
>
> true
>
>
>
>
>
> {code}
> Here's my output of {{{}mvn --version{}}}:
> {code:none}
> Apache Maven 3.8.3 (ff8e977a158738155dc465c6a97ffaf31982d739)
> Maven home: /Users/***/.asdf/installs/maven/3.8.3
> Java version: 17.0.1, vendor: Oracle Corporation, runtime:
> /Users/***/.asdf/installs/java/openjdk-17.0.1
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "12.3.1", arch: "x86_64", family: "mac"
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-compiler-plugin] joakime commented on pull request #88: [MCOMPILER-205] Add a boolean to generate missing package-info classes by default
joakime commented on PR #88: URL: https://github.com/apache/maven-compiler-plugin/pull/88#issuecomment-1092009369 This change in MCOMPILER has started to cause problems in various tooling that scans JARs for bytecode scanning reasons. Those users on limited JVMs (android, java 8 compact builds, embedded systems, etc) are also being impacted by this being true. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MCOMPILER-490) Compilation warning when using BOM dependency in pom.xml
[
https://issues.apache.org/jira/browse/MCOMPILER-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519046#comment-17519046
]
Piotr Zygielo commented on MCOMPILER-490:
-
With this warning one can learn that the BOM is used incorrectly (as in example
pom).
> Compilation warning when using BOM dependency in pom.xml
>
>
> Key: MCOMPILER-490
> URL: https://issues.apache.org/jira/browse/MCOMPILER-490
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.9.0, 3.10.0, 3.10.1
>Reporter: Thomas Smith
>Priority: Minor
>
> When using a BOM dependency in pom.xml with the {{-Xlint:all}} compiler
> argument, maven-compiler-plugin will show the following compiler warning:
> {code:none}
> [WARNING] [path] Unexpected file on path: {code}
> This occurs in maven-compiler-plugin 3.9.0 and later (starting with [this
> commit|https://github.com/apache/maven-compiler-plugin/commit/f17b9e2d9d0c89b76fb5e8f980529534c0c109f6#diff-770d75eb3f1634cb819ccb05b6462d37376807e2170d5b9f415992fd0746f12c]).
> It seems to be happening because maven-compiler-plugin is including .pom
> files for these dependencies in the {{{}$CLASSPATH{}}}.
> Here is a pom.xml that reproduces the issue:
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> com.example
> main
> 1.0
> main
>
> UTF-8
> 17
>
>
>
> com.fasterxml.jackson
> jackson-bom
> 2.13.2.1
> pom
>
>
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.9.0
>
> true
>
> -Xlint:all
>
> true
>
>
>
>
>
> {code}
> Here's my output of {{{}mvn --version{}}}:
> {code:none}
> Apache Maven 3.8.3 (ff8e977a158738155dc465c6a97ffaf31982d739)
> Maven home: /Users/***/.asdf/installs/maven/3.8.3
> Java version: 17.0.1, vendor: Oracle Corporation, runtime:
> /Users/***/.asdf/installs/java/openjdk-17.0.1
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "12.3.1", arch: "x86_64", family: "mac"
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7433) [REGRESSION] Multiple maven instances working on same source tree can lock each other
[
https://issues.apache.org/jira/browse/MNG-7433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519031#comment-17519031
]
Dan Tran commented on MNG-7433:
---
my .mvn/extensions.xml does have
{code:java}
io.takari.maven
takari-smart-builder
0.6.1
{code}
but it is not activated during maven build, and getting rid of it also does
not fix the blocking issue
So far i don't have any luck creating a simple producer. still digging
> [REGRESSION] Multiple maven instances working on same source tree can lock
> each other
> -
>
> Key: MNG-7433
> URL: https://issues.apache.org/jira/browse/MNG-7433
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.5
>Reporter: Dan Tran
>Priority: Major
>
> I have a large multi modules java maven build where:
> * phase 1 - basic build + unit tests + jacoco - 40 min
> * phase 2 - sonar:sonar 20 min
> * phase 3 - final packaging and basic smoke-test - 20 min
> To take advantage of Maven multi-threaded build, during the reactor build,
> one of our maven module spins another instance of Maven to run sonar:sonar
> goal right after the basic build is done.
> This means our phase 2 and phase 3 run in parallel sharing the same source
> tree, same local maven repo (where sonar:sonar should have all needed
> dependencies at the share local maven repo to run its task)
> With maven-3.8.5, parallelization is no longer possible, phase 3 is blocked
> until phase 2 is done.
> I am able to trace it to https://github.com/apache/maven/pull/628 where the
> locking started the happen
> How does the lock mechanic work? there must be a local file where both Maven
> instances are watching each other. Is there an option to disable this lock?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] slawekjaranowski commented on pull request #708: [MNG-7441] 3.8.x Update version of logback
slawekjaranowski commented on PR #708: URL: https://github.com/apache/maven/pull/708#issuecomment-1091963420 In maven-3.8.x build there is the same errors like: ``` Caused by: javax.net.ssl.SSLException: Received fatal alert: protocol_version ``` Root cause (probably), command line executed by verifier : ``` Exit code was non-zero: 1; command line and log = /home/jenkins/jenkins-home/workspace/aven_maven-box_maven_maven-3.8.x/test/core-it-suite/target/apache-maven/bin/mvn --global-settings /home/jenkins/jenkins-home/workspace/aven_maven-box_maven_maven-3.8.x/test/core-it-suite/target/test-classes/settings-remote.xml -e --batch-mode -Dmaven.repo.local=/home/jenkins/jenkins-home/workspace/aven_maven-box_maven_maven-3.8.x/test/it-local-repo install ``` there is missing property in command line `-Dhttps.protocols=TLSv1.2` -- 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] (MCOMPILER-490) Compilation warning when using BOM dependency in pom.xml
Thomas Smith created MCOMPILER-490:
--
Summary: Compilation warning when using BOM dependency in pom.xml
Key: MCOMPILER-490
URL: https://issues.apache.org/jira/browse/MCOMPILER-490
Project: Maven Compiler Plugin
Issue Type: Bug
Affects Versions: 3.10.1, 3.10.0, 3.9.0
Reporter: Thomas Smith
When using a BOM dependency in pom.xml with the {{-Xlint:all}} compiler
argument, maven-compiler-plugin will show the following compiler warning:
{code:none}
[WARNING] [path] Unexpected file on path: {code}
This occurs in maven-compiler-plugin 3.9.0 and later (starting with [this
commit|https://github.com/apache/maven-compiler-plugin/commit/f17b9e2d9d0c89b76fb5e8f980529534c0c109f6#diff-770d75eb3f1634cb819ccb05b6462d37376807e2170d5b9f415992fd0746f12c]).
It seems to be happening because maven-compiler-plugin is including .pom files
for these dependencies in the {{{}$CLASSPATH{}}}.
Here is a pom.xml that reproduces the issue:
{code:xml}
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0
com.example
main
1.0
main
UTF-8
17
com.fasterxml.jackson
jackson-bom
2.13.2.1
pom
org.apache.maven.plugins
maven-compiler-plugin
3.9.0
true
-Xlint:all
true
{code}
Here's my output of {{{}mvn --version{}}}:
{code:none}
Apache Maven 3.8.3 (ff8e977a158738155dc465c6a97ffaf31982d739)
Maven home: /Users/***/.asdf/installs/maven/3.8.3
Java version: 17.0.1, vendor: Oracle Corporation, runtime:
/Users/***/.asdf/installs/java/openjdk-17.0.1
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "12.3.1", arch: "x86_64", family: "mac"
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2063) Adding configuration using with --add-opens or --add-exports fails
[
https://issues.apache.org/jira/browse/SUREFIRE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518964#comment-17518964
]
Daniel Subelman commented on SUREFIRE-2063:
---
You are probably right, but that's not the case with v3.3.0-M5 or earlier.
The exact configuration works perfectly fine with v3.3.0-M5 but fails with
v3.3.0-M6.
The issue is not limited to:
{code:java}
org.junit.platform.commons{code}
It also fails with *+anything+* that uses --add-opens or --add-exports.
Other examples that fail with v3.3.0-M6 but not with v3.3.0-M5 (or earlier):
{code:java}
--add-exports javafx.graphics/com.sun.javafx.application=ALL-UNNAMED
--add-opens javafx.controls/javafx.scene.control.skin=org.controlsfx.controls
--add-opens javafx.graphics/com.sun.glass.ui=ALL-UNNAMED
--add-exports javafx.graphics/com.sun.glass.ui.delegate=ALL-UNNAMED
{code}
> Adding configuration using with --add-opens or --add-exports fails
>
>
> Key: SUREFIRE-2063
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2063
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Daniel Subelman
>Priority: Major
>
> Since v3.3.0-M6 fails when using to export or open a package. The
> failure is produced when using --add-opens or --add-exports in .
> The execution doesn't fail with v3.3.0-M5 or earlier.
> As an example, it fails when using the following :
> {code:java}
>
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
>
> {code}
> The failure log:
> {code:java}
> [INFO] --- maven-surefire-plugin:3.0.0-M6:test (dev) @ testing ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
> Error: Could not find or load main class --add-opens
> Caused by: java.lang.ClassNotFoundException: --add-opens
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 9.157 s
> [INFO] Finished at: 2022-04-06T16:28:23-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (dev) on project
> testing:
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] slawekjaranowski commented on pull request #339: [SUREFIRE-1890] Support TestNG 7.4.0
slawekjaranowski commented on PR #339: URL: https://github.com/apache/maven-surefire/pull/339#issuecomment-1091871234 @dankirkd 3.0.0-M6 was released last week - you can check. -- 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-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518917#comment-17518917
]
Tibor Digana commented on SUREFIRE-2029:
Sharing *AtomicInteger *would be possible with
{code:java}
MavenSession.getExecutionProperties()
{code}
It has to be some Java API object and the key value must be in the form of
expression.
The internal forkCount would be shifted by the previous shifts of concurrent
modules started before.
> Parallel execution but surefire.forkNumber is the same
> --
>
> Key: SUREFIRE-2029
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2029
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.2
>Reporter: Nathan McDonald
>Priority: Minor
> Fix For: waiting-for-apache-feedback
>
>
> We have a multi module maven project, and due to our legacy architecture
> different modules are using the same underlying database.
> We are using the one db per fork strategy mentioned, and each test clears the
> database before running its test.
> This seems to work fine. But when running the full build on azure with:
> {noformat}
> mvn ... -T 1C -pl {modulesToBuild} -amd{noformat}
>
> See output kicking off build like:
> {noformat}
> [INFO] Using the MultiThreadedBuilder implementation with a thread count of
> 8{noformat}
>
> We occasionally see one long running test fail, and have traced cause that
> another test is running in parallel and clearing the database before long
> running test completes . This would only seem to be possible if parallel
> forks running but same surefire.forkNumber being set for multiple forks.
> Outputting logs of when tests start and end, with log outputting
> "Thread#$threadId\{$forkNumber}, e.g. Thread#7\{3} for thread with id 7,
> where surefire.forkNumber is 3
> Looking at logs we can see test starts on thread/fork 1, clears db as
> expected, and 30 seconds later logs that it completes (with error that is
> shown later).
> But we can see just moments later, another test starts up and also clears the
> database, but is using same thread/fork:
> {noformat}
> 2022-03-01T16:30:59.5953417Z 2022-03-01 16:30:59.585 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:30:59.7150510Z 2022-03-01 16:30:59.711 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:78 - Thread#1{1} - running
> setup for
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> …
> {noformat}
> 2022-03-01T16:31:01.1305751Z 2022-03-01 16:31:01.128 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:31:01.6123984Z [INFO] Tests run: 2, Failures: 0, Errors: 0,
> Skipped: 0, Time elapsed: 24.715 s - in
> e.t.b.h.w.c.FinancialStatementReportItemRestControllerIT
> 2022-03-01T16:31:01.6124965Z [INFO] Running
> e.t.b.h.w.c.KeyInformationRestControllerIT{noformat}
> …
> {noformat}
> 2022-03-01T16:31:29.1656587Z 2022-03-01 16:31:29.164 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:94 - Thread#1{1} - complete
> test
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> This isn't consistent though. Can see other cases where this works, but the
> logs found where it is working can see long running test running on separate
> fork:
> Thread#1\{3}
> Obviously there are separate threads/forks running here, so seems like
> somewhere between maven multi module and -T 1C, there is not always
> assigning unique forkNumber to each fork.
> I figure best practice is probably having separate modules not use same db,
> so possibly this issue is existing but not being hit by people as would only
> cause issue if same fork number used for separate modules on different
> databases.
> Still looking into issue our side will update if find workaround or more
> detailed information.
> Our surefire/failsafe config is in the root inherited by all other sub
> modules:
> {code:java}
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
> 2
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
>
>
>org.apache.maven.plugins
>maven-failsafe-plugin
>
> 1
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
> ${project.build.directory}/surefire-reports
>
>
>
>
> integration-test
> verify
>
>
>
> {code}
> mvn version info:
> {noformat}
> Apache Maven 3.8.2 (ea98e05a04480131370aa0c110b8c54cf726c06f)
> Maven home: /usr/local/apache-maven
> Java version: 11.0.13, vendor: Red Hat, Inc., runtime:
>
[jira] [Comment Edited] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518917#comment-17518917
]
Tibor Digana edited comment on SUREFIRE-2029 at 4/7/22 2:22 PM:
Sharing *AtomicInteger* would be possible with
{code:java}
MavenSession.getExecutionProperties()
{code}
It has to be some Java API object and the key value must be in the form of
expression.
The internal forkCount would be shifted by the previous shifts of concurrent
modules started before.
was (Author: tibor17):
Sharing *AtomicInteger *would be possible with
{code:java}
MavenSession.getExecutionProperties()
{code}
It has to be some Java API object and the key value must be in the form of
expression.
The internal forkCount would be shifted by the previous shifts of concurrent
modules started before.
> Parallel execution but surefire.forkNumber is the same
> --
>
> Key: SUREFIRE-2029
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2029
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.2
>Reporter: Nathan McDonald
>Priority: Minor
> Fix For: waiting-for-apache-feedback
>
>
> We have a multi module maven project, and due to our legacy architecture
> different modules are using the same underlying database.
> We are using the one db per fork strategy mentioned, and each test clears the
> database before running its test.
> This seems to work fine. But when running the full build on azure with:
> {noformat}
> mvn ... -T 1C -pl {modulesToBuild} -amd{noformat}
>
> See output kicking off build like:
> {noformat}
> [INFO] Using the MultiThreadedBuilder implementation with a thread count of
> 8{noformat}
>
> We occasionally see one long running test fail, and have traced cause that
> another test is running in parallel and clearing the database before long
> running test completes . This would only seem to be possible if parallel
> forks running but same surefire.forkNumber being set for multiple forks.
> Outputting logs of when tests start and end, with log outputting
> "Thread#$threadId\{$forkNumber}, e.g. Thread#7\{3} for thread with id 7,
> where surefire.forkNumber is 3
> Looking at logs we can see test starts on thread/fork 1, clears db as
> expected, and 30 seconds later logs that it completes (with error that is
> shown later).
> But we can see just moments later, another test starts up and also clears the
> database, but is using same thread/fork:
> {noformat}
> 2022-03-01T16:30:59.5953417Z 2022-03-01 16:30:59.585 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:30:59.7150510Z 2022-03-01 16:30:59.711 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:78 - Thread#1{1} - running
> setup for
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> …
> {noformat}
> 2022-03-01T16:31:01.1305751Z 2022-03-01 16:31:01.128 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:31:01.6123984Z [INFO] Tests run: 2, Failures: 0, Errors: 0,
> Skipped: 0, Time elapsed: 24.715 s - in
> e.t.b.h.w.c.FinancialStatementReportItemRestControllerIT
> 2022-03-01T16:31:01.6124965Z [INFO] Running
> e.t.b.h.w.c.KeyInformationRestControllerIT{noformat}
> …
> {noformat}
> 2022-03-01T16:31:29.1656587Z 2022-03-01 16:31:29.164 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:94 - Thread#1{1} - complete
> test
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> This isn't consistent though. Can see other cases where this works, but the
> logs found where it is working can see long running test running on separate
> fork:
> Thread#1\{3}
> Obviously there are separate threads/forks running here, so seems like
> somewhere between maven multi module and -T 1C, there is not always
> assigning unique forkNumber to each fork.
> I figure best practice is probably having separate modules not use same db,
> so possibly this issue is existing but not being hit by people as would only
> cause issue if same fork number used for separate modules on different
> databases.
> Still looking into issue our side will update if find workaround or more
> detailed information.
> Our surefire/failsafe config is in the root inherited by all other sub
> modules:
> {code:java}
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
> 2
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
>
>
>org.apache.maven.plugins
>maven-failsafe-plugin
>
> 1
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
>
[jira] [Comment Edited] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518886#comment-17518886
]
Tibor Digana edited comment on SUREFIRE-2029 at 4/7/22 1:38 PM:
[~milosh]
Andreas Gudian [~agudian] created this feature. If he meant some guarantees
about isolated projects and -T parameter, coherent behavior across them and
unique numbers, he would implement it so several years ago. He did not mean the
same what you mean now.
He was my colleague in ASF and we talked about it. We know that these
guarantees do not exist for long time.
He wanted to say that the user should not expect limitations in terms of
concurrent JVMs due to these are also controlled by the Maven Core in terms of
parallel modules and the modules are independent, see this sentence:
{noformat}
Maven core allows building modules of multi-module projects in parallel with
the command line option -T. This multiplies the extent of concurrency
configured directly in maven-surefire-plugin.
{noformat}
So, something is under control of the core and some concurrency is controlled
by surefire and the outcome may mean that there would be more than 3 concurrent
JVMs. Maybe 3, maybe 3*N, or even 1 to 3*N.
was (Author: tibor17):
[~milosh]
Andreas Gudian [~agudian] created this feature. If he meant some guarantees
about isolated projects and -T parameter, coherent behavior across them and
unique numbers, he would implement it so several years ago. He did not mean the
same what you mean now.
He was my colleague in ASF and we talked about it. We know for long time these
guarantees do not exist.
He wanted to say that the user should not expect limitations in terms of
concurrent JVMs due to these are also controlled by the Maven Core in terms of
parallel modules and the modules are independent, see this sentence:
{noformat}
Maven core allows building modules of multi-module projects in parallel with
the command line option -T. This multiplies the extent of concurrency
configured directly in maven-surefire-plugin.
{noformat}
So, something is under control of the core and some concurrency is controlled
by surefire and the outcome may mean that there would be more than 3 concurrent
JVMs. Maybe 3, maybe 3*N, or even 1 to 3*N.
> Parallel execution but surefire.forkNumber is the same
> --
>
> Key: SUREFIRE-2029
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2029
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.2
>Reporter: Nathan McDonald
>Priority: Minor
> Fix For: waiting-for-apache-feedback
>
>
> We have a multi module maven project, and due to our legacy architecture
> different modules are using the same underlying database.
> We are using the one db per fork strategy mentioned, and each test clears the
> database before running its test.
> This seems to work fine. But when running the full build on azure with:
> {noformat}
> mvn ... -T 1C -pl {modulesToBuild} -amd{noformat}
>
> See output kicking off build like:
> {noformat}
> [INFO] Using the MultiThreadedBuilder implementation with a thread count of
> 8{noformat}
>
> We occasionally see one long running test fail, and have traced cause that
> another test is running in parallel and clearing the database before long
> running test completes . This would only seem to be possible if parallel
> forks running but same surefire.forkNumber being set for multiple forks.
> Outputting logs of when tests start and end, with log outputting
> "Thread#$threadId\{$forkNumber}, e.g. Thread#7\{3} for thread with id 7,
> where surefire.forkNumber is 3
> Looking at logs we can see test starts on thread/fork 1, clears db as
> expected, and 30 seconds later logs that it completes (with error that is
> shown later).
> But we can see just moments later, another test starts up and also clears the
> database, but is using same thread/fork:
> {noformat}
> 2022-03-01T16:30:59.5953417Z 2022-03-01 16:30:59.585 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:30:59.7150510Z 2022-03-01 16:30:59.711 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:78 - Thread#1{1} - running
> setup for
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> …
> {noformat}
> 2022-03-01T16:31:01.1305751Z 2022-03-01 16:31:01.128 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:31:01.6123984Z [INFO] Tests run: 2, Failures: 0, Errors: 0,
> Skipped: 0, Time elapsed: 24.715 s - in
> e.t.b.h.w.c.FinancialStatementReportItemRestControllerIT
> 2022-03-01T16:31:01.6124965Z [INFO] Running
>
[jira] [Commented] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518886#comment-17518886
]
Tibor Digana commented on SUREFIRE-2029:
[~milosh]
Andreas Gudian [~agudian] created this feature. If he meant some guarantees
about isolated projects and -T parameter, coherent behavior across them and
unique numbers, he would implement it so several years ago. He did not mean the
same what you mean now.
He was my colleague in ASF and we talked about it. We know for long time these
guarantees do not exist.
He wanted to say that the user should not expect limitations in terms of
concurrent JVMs due to these are also controlled by the Maven Core in terms of
parallel modules and the modules are independent, see this sentence:
{noformat}
Maven core allows building modules of multi-module projects in parallel with
the command line option -T. This multiplies the extent of concurrency
configured directly in maven-surefire-plugin.
{noformat}
So, something is under control of the core and some concurrency is controlled
by surefire and the outcome may mean that there would be more than 3 concurrent
JVMs. Maybe 3, maybe 3*N, or even 1 to 3*N.
> Parallel execution but surefire.forkNumber is the same
> --
>
> Key: SUREFIRE-2029
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2029
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.2
>Reporter: Nathan McDonald
>Priority: Minor
> Fix For: waiting-for-apache-feedback
>
>
> We have a multi module maven project, and due to our legacy architecture
> different modules are using the same underlying database.
> We are using the one db per fork strategy mentioned, and each test clears the
> database before running its test.
> This seems to work fine. But when running the full build on azure with:
> {noformat}
> mvn ... -T 1C -pl {modulesToBuild} -amd{noformat}
>
> See output kicking off build like:
> {noformat}
> [INFO] Using the MultiThreadedBuilder implementation with a thread count of
> 8{noformat}
>
> We occasionally see one long running test fail, and have traced cause that
> another test is running in parallel and clearing the database before long
> running test completes . This would only seem to be possible if parallel
> forks running but same surefire.forkNumber being set for multiple forks.
> Outputting logs of when tests start and end, with log outputting
> "Thread#$threadId\{$forkNumber}, e.g. Thread#7\{3} for thread with id 7,
> where surefire.forkNumber is 3
> Looking at logs we can see test starts on thread/fork 1, clears db as
> expected, and 30 seconds later logs that it completes (with error that is
> shown later).
> But we can see just moments later, another test starts up and also clears the
> database, but is using same thread/fork:
> {noformat}
> 2022-03-01T16:30:59.5953417Z 2022-03-01 16:30:59.585 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:30:59.7150510Z 2022-03-01 16:30:59.711 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:78 - Thread#1{1} - running
> setup for
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> …
> {noformat}
> 2022-03-01T16:31:01.1305751Z 2022-03-01 16:31:01.128 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:31:01.6123984Z [INFO] Tests run: 2, Failures: 0, Errors: 0,
> Skipped: 0, Time elapsed: 24.715 s - in
> e.t.b.h.w.c.FinancialStatementReportItemRestControllerIT
> 2022-03-01T16:31:01.6124965Z [INFO] Running
> e.t.b.h.w.c.KeyInformationRestControllerIT{noformat}
> …
> {noformat}
> 2022-03-01T16:31:29.1656587Z 2022-03-01 16:31:29.164 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:94 - Thread#1{1} - complete
> test
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> This isn't consistent though. Can see other cases where this works, but the
> logs found where it is working can see long running test running on separate
> fork:
> Thread#1\{3}
> Obviously there are separate threads/forks running here, so seems like
> somewhere between maven multi module and -T 1C, there is not always
> assigning unique forkNumber to each fork.
> I figure best practice is probably having separate modules not use same db,
> so possibly this issue is existing but not being hit by people as would only
> cause issue if same fork number used for separate modules on different
> databases.
> Still looking into issue our side will update if find workaround or more
> detailed information.
> Our surefire/failsafe config is in the root inherited by all other sub
>
[jira] [Comment Edited] (SUREFIRE-2058) Corrupted STDOUT by directly writing to native stream in forked JVM 1 with UTF-8 console logging
[
https://issues.apache.org/jira/browse/SUREFIRE-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518885#comment-17518885
]
Zoltan Meze edited comment on SUREFIRE-2058 at 4/7/22 1:33 PM:
---
I believe this is caused by not clearing output buffer after reading chunks in
AbstractStreamDecoder#readString.
In first iteration decodeString end up with underflow, decoding only 1023 out
of 1024 characters and leaving 1 space in output char buffer. Because the 1
remaining space, the output is never flipped/cleared and second iteration
always end up with overflow.
- In first scenario it force reads one additional byte. This fills output
buffer completely so it is able to exit the loop. Leftover input bytes are
leaving the channel corrupted.
- In second scenario output buffer after overflow always ends up with 1
leftover space remaining. This is causing readString to be stuck in infinite
loop.
I am currently testing this, seems to be working fine. But not sure if this is
correct approach, I am not familiar with this code.
https://github.com/apache/maven-surefire/compare/master...zoltanmeze:SUREFIRE-2058
was (Author: JIRAUSER287608):
I believe this is caused by not clearing output buffer after reading chunks in
AbstractStreamDecoder#readString.
In first iteration decodeString end up with underflow, decoding only 1023 out
of 1024 characters and leaving 1 space in output char buffer. Because the 1
remaining space, the output is never flipped/cleared and second iteration
always end up with overflow.
- In first scenario it force reads one additional byte. This fills output
buffer completely so it is able to exit the loop. Leftover input bytes are
leaving the channel corrupted.
- In second scenario output buffer after overflow always ends up with 1
leftover space remaining. This is causing readString to be stuck in infinite
loop.
I am currently testing this, seems to be working fine. But not sure if this is
correct approach.
https://github.com/apache/maven-surefire/compare/master...zoltanmeze:SUREFIRE-2058
> Corrupted STDOUT by directly writing to native stream in forked JVM 1 with
> UTF-8 console logging
>
>
> Key: SUREFIRE-2058
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2058
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M6
>Reporter: Zoltan Meze
>Priority: Blocker
>
> With 3.0.0-M6 surefire and slf4j + logback, most test runs end up with:
> {code:java}
> [WARNING] Corrupted channel by directly writing to native stream in forked
> JVM 1. {code}
> This only affects *3.0.0-M6* (3.0.0-M5 version is working fine in test
> project).
>
> After some digging, there are two different scenarios (most likely caused by
> the same issue):
> * 2-byte character at position 1023 (or N * 1024 - 1) in log message is
> causing the following warning
> {code:java}
> [WARNING] Corrupted channel by directly writing to native stream in forked
> JVM 1.
> {code}
> To reproduce this issue logback (with slf4j) should be used.
> Not able to reproduce with System.out.println.
> * 4-byte character at position 1023 (or N * 1024 - 1) in log message.
> Can be reproduced with System.out.println (logback not required in this case).
> This blocks surefire entirely at (from jstack):
> {code:java}
> "fork-1-event-thread" #30 daemon prio=5 os_prio=0 cpu=32350.09ms
> elapsed=32.94s tid=0x7ff8292d7800 nid=0x3caef runnable
> [0x7ff7876f6000]
>java.lang.Thread.State: RUNNABLE
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.decodeString(AbstractStreamDecoder.java:350)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.readString(AbstractStreamDecoder.java:322)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.readString(AbstractStreamDecoder.java:196)
> at
> org.apache.maven.surefire.stream.EventDecoder.decode(EventDecoder.java:176)
> at
> org.apache.maven.plugin.surefire.extensions.EventConsumerThread.run(EventConsumerThread.java:73)
> {code}
>
> Project with reproducible tests (for both scenarios, more in README):
> [https://github.com/zoltanmeze/surefire-corrupted-channel]
>
> One workaround on M6 for now is to use different charset (instead of default
> UTF-8) or limit message size.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2058) Corrupted STDOUT by directly writing to native stream in forked JVM 1 with UTF-8 console logging
[
https://issues.apache.org/jira/browse/SUREFIRE-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518885#comment-17518885
]
Zoltan Meze commented on SUREFIRE-2058:
---
I believe this is caused by not clearing output buffer after reading chunks in
AbstractStreamDecoder#readString.
In first iteration decodeString end up with underflow, decoding only 1023 out
of 1024 characters and leaving 1 space in output char buffer. Because the 1
remaining space, the output is never flipped/cleared and second iteration
always end up with overflow.
- In first scenario it force reads one additional byte. This fills output
buffer completely so it is able to exit the loop. Leftover input bytes are
leaving the channel corrupted.
- In second scenario output buffer after overflow always ends up with 1
leftover space remaining. This is causing readString to be stuck in infinite
loop.
I am currently testing this, seems to be working fine. But not sure if this is
correct approach.
https://github.com/apache/maven-surefire/compare/master...zoltanmeze:SUREFIRE-2058
> Corrupted STDOUT by directly writing to native stream in forked JVM 1 with
> UTF-8 console logging
>
>
> Key: SUREFIRE-2058
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2058
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M6
>Reporter: Zoltan Meze
>Priority: Blocker
>
> With 3.0.0-M6 surefire and slf4j + logback, most test runs end up with:
> {code:java}
> [WARNING] Corrupted channel by directly writing to native stream in forked
> JVM 1. {code}
> This only affects *3.0.0-M6* (3.0.0-M5 version is working fine in test
> project).
>
> After some digging, there are two different scenarios (most likely caused by
> the same issue):
> * 2-byte character at position 1023 (or N * 1024 - 1) in log message is
> causing the following warning
> {code:java}
> [WARNING] Corrupted channel by directly writing to native stream in forked
> JVM 1.
> {code}
> To reproduce this issue logback (with slf4j) should be used.
> Not able to reproduce with System.out.println.
> * 4-byte character at position 1023 (or N * 1024 - 1) in log message.
> Can be reproduced with System.out.println (logback not required in this case).
> This blocks surefire entirely at (from jstack):
> {code:java}
> "fork-1-event-thread" #30 daemon prio=5 os_prio=0 cpu=32350.09ms
> elapsed=32.94s tid=0x7ff8292d7800 nid=0x3caef runnable
> [0x7ff7876f6000]
>java.lang.Thread.State: RUNNABLE
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.decodeString(AbstractStreamDecoder.java:350)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.readString(AbstractStreamDecoder.java:322)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.readString(AbstractStreamDecoder.java:196)
> at
> org.apache.maven.surefire.stream.EventDecoder.decode(EventDecoder.java:176)
> at
> org.apache.maven.plugin.surefire.extensions.EventConsumerThread.run(EventConsumerThread.java:73)
> {code}
>
> Project with reproducible tests (for both scenarios, more in README):
> [https://github.com/zoltanmeze/surefire-corrupted-channel]
>
> One workaround on M6 for now is to use different charset (instead of default
> UTF-8) or limit message size.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] dankirkd commented on pull request #339: [SUREFIRE-1890] Support TestNG 7.4.0
dankirkd commented on PR #339: URL: https://github.com/apache/maven-surefire/pull/339#issuecomment-1091707015 @Tibor17 Can you confirm that 3.0.0-M6 supports TestNG 7.5? -- 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] rmannibucau commented on pull request #708: [MNG-7441] 3.8.x Update version of logback
rmannibucau commented on PR #708: URL: https://github.com/apache/maven/pull/708#issuecomment-1091672866 If it is only about `LogbackConfiguration` it can be done by reflection and the dep dropped, no? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] khmarbaise commented on pull request #708: [MNG-7441] 3.8.x Update version of logback
khmarbaise commented on PR #708: URL: https://github.com/apache/maven/pull/708#issuecomment-1091668627 Maven 3.8.X ist built also with JDK 7... https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.8.x/ -- 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] michael-o commented on pull request #708: [MNG-7441] 3.8.x Update version of logback
michael-o commented on PR #708: URL: https://github.com/apache/maven/pull/708#issuecomment-1091663985 Java 7? -- 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] khmarbaise commented on pull request #708: [MNG-7441] 3.8.x Update version of logback
khmarbaise commented on PR #708: URL: https://github.com/apache/maven/pull/708#issuecomment-1091660881 This seemed to be the reason: `[ERROR] Plugin org.apache.maven.plugins:maven-dependency-plugin:3.1.1 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-dependency-plugin:jar:3.1.1: Could not transfer artifact org.apache.maven.plugins:maven-dependency-plugin:pom:3.1.1 from/to central (https://repo1.maven.org/maven2): transfer failed for https://repo1.maven.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/3.1.1/maven-dependency-plugin-3.1.1.pom: Received fatal alert: protocol_version -> [Help 1]` -- 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] Tibor17 commented on a diff in pull request #505: [SUREFIRE-2055] Always show random seed
Tibor17 commented on code in PR #505:
URL: https://github.com/apache/maven-surefire/pull/505#discussion_r844516213
##
surefire-its/src/test/java/org/apache/maven/surefire/its/RunOrderIT.java:
##
@@ -97,7 +97,17 @@ public void testRandomJUnit4SameSeed()
}
}
}
-
+
+@Test
+public void testRandomJUnit4PrintSeed()
+{
+long seed = 0L;
+OutputValidator validator = executeWithRandomOrder( "junit4", seed );
+validator.verifyTextInLog( "To reproduce ordering use flag" );
+validator = executeWithRandomOrder( "junit4" );
+validator.verifyTextInLog( "To reproduce ordering use flag" );
Review Comment:
@slawekjaranowski Do you remember all the years we solved together with
Robert and Infra team because the Windows paths were limited on the file
system? They are still limitted however the limit is longer but it still
exists! Also the infra team prolonged the limit of CMD line in bash but it
still exists.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (MCOMPILER-481) JPMS Regression: cannot access (requires static module not include anymore)
[
https://issues.apache.org/jira/browse/MCOMPILER-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MCOMPILER-481:
---
Priority: Blocker (was: Major)
> JPMS Regression: cannot access (requires static module not include
> anymore)
> ---
>
> Key: MCOMPILER-481
> URL: https://issues.apache.org/jira/browse/MCOMPILER-481
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Simone Bordet
>Assignee: Olivier Lamy
>Priority: Blocker
> Fix For: 3.10.0
>
> Attachments: compiler-bug.tar.gz
>
>
> Version 3.8.1 is not affected.
> The problem lies in how the module-path is constructed by the
> maven-compiler-plugin – not sure what changes from 3.8.1 caused this.
> In 3.8.1:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> In 3.9.0:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> Running with 3.9.0 yields:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.9.0:testCompile
> (default-testCompile) on project compiler-bug-app: Compilation failure
> [ERROR]
> /home/simon/tmp/compiler-bug/app/src/test/java/org/test/app/MainTest.java:[12,38]
> cannot access org.eclipse.jetty.util.ajax.JSON
> [ERROR] class file for org.eclipse.jetty.util.ajax.JSON not found {code}
> Class {{JSON}} is in {{{}jetty-util-10.0.7.jar{}}}.
> In 3.9.0 this jar is missing from the module-path, causing the error.
> Attached you can find a reproducer: switch the maven-compiler-plugin version
> from 3.8.1 (works) to 3.9.0 (does not work) in the main POM.
--
This message was sent by Atlassian
[GitHub] [maven] cstamas commented on pull request #708: [MNG-7441] 3.8.x Update version of logback
cstamas commented on PR #708: URL: https://github.com/apache/maven/pull/708#issuecomment-1091473277 Any idea why Jenkins failed this build? -- 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-7441) Update Version of Logback to Address CVE-2021-42550
[
https://issues.apache.org/jira/browse/MNG-7441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518754#comment-17518754
]
Michael Osipov commented on MNG-7441:
-
Doens't this apply to 3.9.x and 4.x as well?
> Update Version of Logback to Address CVE-2021-42550
> ---
>
> Key: MNG-7441
> URL: https://issues.apache.org/jira/browse/MNG-7441
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.8.5
>Reporter: Mac Hale
>Priority: Major
> Fix For: 3.8.6
>
>
> [CVE-2021-42550|https://nvd.nist.gov/vuln/detail/CVE-2021-42550] is present
> in Logback versions 1.2.7 and earlier. Maven uses v 1.2.1. Please update to
> Logback 1.2.9, which includes a fix as per
> [https://jira.qos.ch/browse/LOGBACK-1591|[https://jira.qos.ch/browse/LOGBACK-1591].]
> I see ch.qos.logback 1.2.1 in {{./pom.xml}} and ch.qos.logback without a
> version specified in {{./maven-embedder/pom.xml}}
> But I'm no expert on this code base so it's possible there are other
> versioned references.
> Edit: One could argue, as the Logback team has done, that the CVE is
> unimportant since in order to exploit it one must already have compromised
> the system. However, security scanners pick this up as an issue, causing
> unnecessary work and justifications.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] michael-o commented on pull request #708: [MNG-7441] 3.8.x Update version of logback
michael-o commented on PR #708: URL: https://github.com/apache/maven/pull/708#issuecomment-1091436057 Nice waste of time for bogus as you have said ;-) -- 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-7449) [REGRESSION] StringVisitorModelInterpolator NullPointerException
[
https://issues.apache.org/jira/browse/MNG-7449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518740#comment-17518740
]
ASF GitHub Bot commented on MNG-7449:
-
michael-o commented on PR #297:
URL: https://github.com/apache/maven-site/pull/297#issuecomment-1091431646
> -1 This needs to be undone, as explained in comment
https://issues.apache.org/jira/browse/MNG-7449?focusedCommentId=17518729=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17518729
True. Simply wrong usage.
> [REGRESSION] StringVisitorModelInterpolator NullPointerException
>
>
> Key: MNG-7449
> URL: https://issues.apache.org/jira/browse/MNG-7449
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.8.5
>Reporter: Ronnie de Lang
>Priority: Major
>
> Since Maven 3.8.5 our own custom Maven plugin is failing with a
> NullPointerException when trying to interpolate Maven properties in a Maven
> model.
> Code:
> {code:java}
> StringVisitorModelInterpolator interpolator = new
> StringVisitorModelInterpolator();
> interpolated = interpolator.interpolateModel(model, null, new
> DefaultModelBuildingRequest(), new ModelProblemCollector() {
> @Override
> public void add(ModelProblemCollectorRequest
> modelProblemCollectorRequest) {
> problems.add(modelProblemCollectorRequest);
> }
> }); {code}
> Stacktrace:
> {code:java}
> [ERROR] Failed to execute goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> (default) on project DNL_PMDM_HelloYou: Execution default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.: NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> (default) on project DNL_PMDM_HelloYou: Execution default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:306)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:211)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:165)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:121)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:127)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:148)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:301)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:211)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:165)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:121)
> at
>
[GitHub] [maven-site] michael-o commented on pull request #297: Document known 3.8.5 issue MNG-7449
michael-o commented on PR #297: URL: https://github.com/apache/maven-site/pull/297#issuecomment-1091431646 > -1 This needs to be undone, as explained in comment https://issues.apache.org/jira/browse/MNG-7449?focusedCommentId=17518729=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17518729 True. Simply wrong usage. -- 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-7449) [REGRESSION] StringVisitorModelInterpolator NullPointerException
[
https://issues.apache.org/jira/browse/MNG-7449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518738#comment-17518738
]
Michael Osipov commented on MNG-7449:
-
I agree with [~cstamas].
> [REGRESSION] StringVisitorModelInterpolator NullPointerException
>
>
> Key: MNG-7449
> URL: https://issues.apache.org/jira/browse/MNG-7449
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.8.5
>Reporter: Ronnie de Lang
>Priority: Major
>
> Since Maven 3.8.5 our own custom Maven plugin is failing with a
> NullPointerException when trying to interpolate Maven properties in a Maven
> model.
> Code:
> {code:java}
> StringVisitorModelInterpolator interpolator = new
> StringVisitorModelInterpolator();
> interpolated = interpolator.interpolateModel(model, null, new
> DefaultModelBuildingRequest(), new ModelProblemCollector() {
> @Override
> public void add(ModelProblemCollectorRequest
> modelProblemCollectorRequest) {
> problems.add(modelProblemCollectorRequest);
> }
> }); {code}
> Stacktrace:
> {code:java}
> [ERROR] Failed to execute goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> (default) on project DNL_PMDM_HelloYou: Execution default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.: NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> (default) on project DNL_PMDM_HelloYou: Execution default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:306)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:211)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:165)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:121)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:127)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:148)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:301)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:211)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:165)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:121)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
>
[jira] [Commented] (MNG-7449) [REGRESSION] StringVisitorModelInterpolator NullPointerException
[
https://issues.apache.org/jira/browse/MNG-7449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518733#comment-17518733
]
ASF GitHub Bot commented on MNG-7449:
-
cstamas commented on PR #297:
URL: https://github.com/apache/maven-site/pull/297#issuecomment-1091425104
-1 This needs to be undone, as explained in comment
https://issues.apache.org/jira/browse/MNG-7449?focusedCommentId=17518729=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17518729
> [REGRESSION] StringVisitorModelInterpolator NullPointerException
>
>
> Key: MNG-7449
> URL: https://issues.apache.org/jira/browse/MNG-7449
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.8.5
>Reporter: Ronnie de Lang
>Priority: Major
>
> Since Maven 3.8.5 our own custom Maven plugin is failing with a
> NullPointerException when trying to interpolate Maven properties in a Maven
> model.
> Code:
> {code:java}
> StringVisitorModelInterpolator interpolator = new
> StringVisitorModelInterpolator();
> interpolated = interpolator.interpolateModel(model, null, new
> DefaultModelBuildingRequest(), new ModelProblemCollector() {
> @Override
> public void add(ModelProblemCollectorRequest
> modelProblemCollectorRequest) {
> problems.add(modelProblemCollectorRequest);
> }
> }); {code}
> Stacktrace:
> {code:java}
> [ERROR] Failed to execute goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> (default) on project DNL_PMDM_HelloYou: Execution default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.: NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> (default) on project DNL_PMDM_HelloYou: Execution default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:306)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:211)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:165)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:121)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:127)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:148)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:301)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:211)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:165)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:121)
> at
>
[GitHub] [maven-site] cstamas commented on pull request #297: Document known 3.8.5 issue MNG-7449
cstamas commented on PR #297: URL: https://github.com/apache/maven-site/pull/297#issuecomment-1091425104 -1 This needs to be undone, as explained in comment https://issues.apache.org/jira/browse/MNG-7449?focusedCommentId=17518729=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17518729 -- 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-7449) [REGRESSION] StringVisitorModelInterpolator NullPointerException
[
https://issues.apache.org/jira/browse/MNG-7449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518729#comment-17518729
]
Tamás Cservenák commented on MNG-7449:
--
IMHO you are doing it wrong here: IF we talk about this class:
https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/interpolation/StringVisitorModelInterpolator.java#L91
then for sure you are doing it wrong.
As you can see (lines 89, 90), this is a component, it means it is managed (and
injected) by container, and is NOT MEANT to be instantiated manually as you do
({{StringVisitorModelInterpolator interpolator = new
StringVisitorModelInterpolator();}}). Your fix that will work from introduction
of this class (Maven 3.6.2) and latest Maven version is:
Instead using {{new}} to instantiate it, inject the singleton instance like
this (if in Mojo):
{noformat}
@Inject
private StringVisitorModelInterpolator interpolator;
{noformat}
And then use {{interpolator}} as before.
This is NOT a regression either: as user is self-instantiating a component
instance, he does not inject fields that otherwise container would inject. This
is plain misuse of the class. If injected as component, the code above would
not NPE and would work from Maven 3.6.2 to latest release.
> [REGRESSION] StringVisitorModelInterpolator NullPointerException
>
>
> Key: MNG-7449
> URL: https://issues.apache.org/jira/browse/MNG-7449
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.8.5
>Reporter: Ronnie de Lang
>Priority: Major
>
> Since Maven 3.8.5 our own custom Maven plugin is failing with a
> NullPointerException when trying to interpolate Maven properties in a Maven
> model.
> Code:
> {code:java}
> StringVisitorModelInterpolator interpolator = new
> StringVisitorModelInterpolator();
> interpolated = interpolator.interpolateModel(model, null, new
> DefaultModelBuildingRequest(), new ModelProblemCollector() {
> @Override
> public void add(ModelProblemCollectorRequest
> modelProblemCollectorRequest) {
> problems.add(modelProblemCollectorRequest);
> }
> }); {code}
> Stacktrace:
> {code:java}
> [ERROR] Failed to execute goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> (default) on project DNL_PMDM_HelloYou: Execution default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.: NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> (default) on project DNL_PMDM_HelloYou: Execution default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:306)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:211)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:165)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:121)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:127)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by:
[jira] [Updated] (MNG-7441) Update Version of Logback to Address CVE-2021-42550
[
https://issues.apache.org/jira/browse/MNG-7441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MNG-7441:
-
Fix Version/s: 3.8.6
> Update Version of Logback to Address CVE-2021-42550
> ---
>
> Key: MNG-7441
> URL: https://issues.apache.org/jira/browse/MNG-7441
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.8.5
>Reporter: Mac Hale
>Priority: Major
> Fix For: 3.8.6
>
>
> [CVE-2021-42550|https://nvd.nist.gov/vuln/detail/CVE-2021-42550] is present
> in Logback versions 1.2.7 and earlier. Maven uses v 1.2.1. Please update to
> Logback 1.2.9, which includes a fix as per
> [https://jira.qos.ch/browse/LOGBACK-1591|[https://jira.qos.ch/browse/LOGBACK-1591].]
> I see ch.qos.logback 1.2.1 in {{./pom.xml}} and ch.qos.logback without a
> version specified in {{./maven-embedder/pom.xml}}
> But I'm no expert on this code base so it's possible there are other
> versioned references.
> Edit: One could argue, as the Logback team has done, that the CVE is
> unimportant since in order to exploit it one must already have compromised
> the system. However, security scanners pick this up as an issue, causing
> unnecessary work and justifications.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] cstamas opened a new pull request, #708: [MNG-7441] Update version of loback
cstamas opened a new pull request, #708: URL: https://github.com/apache/maven/pull/708 This issue is fluke, as logback is actually optional dependency, but still, to cut reports like these from root, let's do this update. --- https://issues.apache.org/jira/browse/MNG-7441 -- 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] (MNG-7433) [REGRESSION] Multiple maven instances working on same source tree can lock each other
[ https://issues.apache.org/jira/browse/MNG-7433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518670#comment-17518670 ] Tamás Cservenák edited comment on MNG-7433 at 4/7/22 8:52 AM: -- I am on Linux as well (Linux Mint 20.3 + Temurin 11.0.14). Can you create a reproducer, or if project does not matter, at least a sequence how you invoke maven instances that lock up? was (Author: cstamas): I am on Linux as well (Linux Mint 20.3 + Temurin 11.0.14). Can you create a reproducer (or if project does not matter), or at least a sequence how you invoke maven instances that lock up? > [REGRESSION] Multiple maven instances working on same source tree can lock > each other > - > > Key: MNG-7433 > URL: https://issues.apache.org/jira/browse/MNG-7433 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Dan Tran >Priority: Major > > I have a large multi modules java maven build where: > * phase 1 - basic build + unit tests + jacoco - 40 min > * phase 2 - sonar:sonar 20 min > * phase 3 - final packaging and basic smoke-test - 20 min > To take advantage of Maven multi-threaded build, during the reactor build, > one of our maven module spins another instance of Maven to run sonar:sonar > goal right after the basic build is done. > This means our phase 2 and phase 3 run in parallel sharing the same source > tree, same local maven repo (where sonar:sonar should have all needed > dependencies at the share local maven repo to run its task) > With maven-3.8.5, parallelization is no longer possible, phase 3 is blocked > until phase 2 is done. > I am able to trace it to https://github.com/apache/maven/pull/628 where the > locking started the happen > How does the lock mechanic work? there must be a local file where both Maven > instances are watching each other. Is there an option to disable this lock? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7429) The classloader containing build extensions should be used throughout the build
[ https://issues.apache.org/jira/browse/MNG-7429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518686#comment-17518686 ] Christoph Läubrich commented on MNG-7429: - [~gnodet] I think this is probbaly obsolete now as you solved your issue without a global classloader already? > The classloader containing build extensions should be used throughout the > build > --- > > Key: MNG-7429 > URL: https://issues.apache.org/jira/browse/MNG-7429 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5, 3.9.0, 4.0.0-alpha-1 >Reporter: Guillaume Nodet >Priority: Major > Labels: Regression > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7449) [REGRESSION] StringVisitorModelInterpolator NullPointerException
[
https://issues.apache.org/jira/browse/MNG-7449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518685#comment-17518685
]
ASF GitHub Bot commented on MNG-7449:
-
laeubi commented on PR #297:
URL: https://github.com/apache/maven-site/pull/297#issuecomment-1091299272
As mentioned in the JIRA I think using the class directly is a coding error
if the caller does not want to inject all requirements itself.
If that's not desired `DefaultModelBuilderFactory` has to be used.
> [REGRESSION] StringVisitorModelInterpolator NullPointerException
>
>
> Key: MNG-7449
> URL: https://issues.apache.org/jira/browse/MNG-7449
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.8.5
>Reporter: Ronnie de Lang
>Priority: Major
>
> Since Maven 3.8.5 our own custom Maven plugin is failing with a
> NullPointerException when trying to interpolate Maven properties in a Maven
> model.
> Code:
> {code:java}
> StringVisitorModelInterpolator interpolator = new
> StringVisitorModelInterpolator();
> interpolated = interpolator.interpolateModel(model, null, new
> DefaultModelBuildingRequest(), new ModelProblemCollector() {
> @Override
> public void add(ModelProblemCollectorRequest
> modelProblemCollectorRequest) {
> problems.add(modelProblemCollectorRequest);
> }
> }); {code}
> Stacktrace:
> {code:java}
> [ERROR] Failed to execute goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> (default) on project DNL_PMDM_HelloYou: Execution default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.: NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> (default) on project DNL_PMDM_HelloYou: Execution default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:306)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:211)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:165)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:121)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:127)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:148)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:301)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:211)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:165)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:121)
> at
>
[GitHub] [maven-site] laeubi commented on pull request #297: Document known 3.8.5 issue MNG-7449
laeubi commented on PR #297: URL: https://github.com/apache/maven-site/pull/297#issuecomment-1091299272 As mentioned in the JIRA I think using the class directly is a coding error if the caller does not want to inject all requirements itself. If that's not desired `DefaultModelBuilderFactory` has to be used. -- 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-7449) [REGRESSION] StringVisitorModelInterpolator NullPointerException
[
https://issues.apache.org/jira/browse/MNG-7449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518684#comment-17518684
]
Christoph Läubrich commented on MNG-7449:
-
I think you need to use DefaultModelBuilderFactory instead, that would be
backward compatible and fix your issue:
A factory to create model builder instances *when no dependency injection is
available*. Note: This class is only meant as a utility for developers
that want to employ the model builder outside of the Maven build system.
> [REGRESSION] StringVisitorModelInterpolator NullPointerException
>
>
> Key: MNG-7449
> URL: https://issues.apache.org/jira/browse/MNG-7449
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.8.5
>Reporter: Ronnie de Lang
>Priority: Major
>
> Since Maven 3.8.5 our own custom Maven plugin is failing with a
> NullPointerException when trying to interpolate Maven properties in a Maven
> model.
> Code:
> {code:java}
> StringVisitorModelInterpolator interpolator = new
> StringVisitorModelInterpolator();
> interpolated = interpolator.interpolateModel(model, null, new
> DefaultModelBuildingRequest(), new ModelProblemCollector() {
> @Override
> public void add(ModelProblemCollectorRequest
> modelProblemCollectorRequest) {
> problems.add(modelProblemCollectorRequest);
> }
> }); {code}
> Stacktrace:
> {code:java}
> [ERROR] Failed to execute goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> (default) on project DNL_PMDM_HelloYou: Execution default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.: NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> (default) on project DNL_PMDM_HelloYou: Execution default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:306)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:211)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:165)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:121)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:127)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:148)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:301)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:211)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:165)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:121)
> at
>
[GitHub] [maven-resolver] caiwei-ebay commented on pull request #161: [MRESOLVER-248] Make BF and DF collectors coexists
caiwei-ebay commented on PR #161: URL: https://github.com/apache/maven-resolver/pull/161#issuecomment-1091274941 > @caiwei-ebay all looking good here? Any proposal to change/add? Looks good to me. Thanks. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7433) [REGRESSION] Multiple maven instances working on same source tree can lock each other
[ https://issues.apache.org/jira/browse/MNG-7433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518671#comment-17518671 ] Tamás Cservenák commented on MNG-7433: -- Are you using takari lifecycle or takari local repo maybe? > [REGRESSION] Multiple maven instances working on same source tree can lock > each other > - > > Key: MNG-7433 > URL: https://issues.apache.org/jira/browse/MNG-7433 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Dan Tran >Priority: Major > > I have a large multi modules java maven build where: > * phase 1 - basic build + unit tests + jacoco - 40 min > * phase 2 - sonar:sonar 20 min > * phase 3 - final packaging and basic smoke-test - 20 min > To take advantage of Maven multi-threaded build, during the reactor build, > one of our maven module spins another instance of Maven to run sonar:sonar > goal right after the basic build is done. > This means our phase 2 and phase 3 run in parallel sharing the same source > tree, same local maven repo (where sonar:sonar should have all needed > dependencies at the share local maven repo to run its task) > With maven-3.8.5, parallelization is no longer possible, phase 3 is blocked > until phase 2 is done. > I am able to trace it to https://github.com/apache/maven/pull/628 where the > locking started the happen > How does the lock mechanic work? there must be a local file where both Maven > instances are watching each other. Is there an option to disable this lock? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7433) [REGRESSION] Multiple maven instances working on same source tree can lock each other
[ https://issues.apache.org/jira/browse/MNG-7433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518670#comment-17518670 ] Tamás Cservenák commented on MNG-7433: -- I am on Linux as well (Linux Mint 20.3 + Temurin 11.0.14). Can you create a reproducer (or if project does not matter), or at least a sequence how you invoke maven instances that lock up? > [REGRESSION] Multiple maven instances working on same source tree can lock > each other > - > > Key: MNG-7433 > URL: https://issues.apache.org/jira/browse/MNG-7433 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Dan Tran >Priority: Major > > I have a large multi modules java maven build where: > * phase 1 - basic build + unit tests + jacoco - 40 min > * phase 2 - sonar:sonar 20 min > * phase 3 - final packaging and basic smoke-test - 20 min > To take advantage of Maven multi-threaded build, during the reactor build, > one of our maven module spins another instance of Maven to run sonar:sonar > goal right after the basic build is done. > This means our phase 2 and phase 3 run in parallel sharing the same source > tree, same local maven repo (where sonar:sonar should have all needed > dependencies at the share local maven repo to run its task) > With maven-3.8.5, parallelization is no longer possible, phase 3 is blocked > until phase 2 is done. > I am able to trace it to https://github.com/apache/maven/pull/628 where the > locking started the happen > How does the lock mechanic work? there must be a local file where both Maven > instances are watching each other. Is there an option to disable this lock? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MWAR-450) ISO8859-1 properties files get changed into UTF-8 when filtered
[
https://issues.apache.org/jira/browse/MWAR-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518665#comment-17518665
]
Dennis Lundberg commented on MWAR-450:
--
We have a working implementation now, and will continue to write some tests to
verify the old and new behavior.
> ISO8859-1 properties files get changed into UTF-8 when filtered
> ---
>
> Key: MWAR-450
> URL: https://issues.apache.org/jira/browse/MWAR-450
> Project: Maven WAR Plugin
> Issue Type: Improvement
> Components: filtering
>Affects Versions: 3.3.2
>Reporter: Dennis Lundberg
>Priority: Major
>
> This issue is similar to
> https://issues.apache.org/jira/browse/MRESOURCES-171, but for filtering web
> resources in maven-war-plugin.
> We add properties files that have ISO-8859-1 encoding, as per the Java 8
> requirements, as web resources in a war project. When these resources are
> filtered they get converted to the encoding specified by the
> project.build.sourceEncoding. There is a parameter resourceEncoding that can
> be used to change the encoding for web reources, but it applies to all web
> resource files which is not always what you want.
> Here is the configuration used:
> {code:xml}
>
>
>
> org.apache.maven.plugins
> maven-war-plugin
> 3.3.2
>
>
>
> WEB-INF/classes
> true
> src/main/webapp/WEB-INF/classes
>
>
>
>
>
>
> {code}
> We propose to add a new parameter propertiesEncoding to the AbstractWarMojo.
> If the value of this parameter is set and filtering is enabled and a web
> resource file is a properties file, then the value of the parameter is used
> as encoding when filtering the file.
> If the parameter is not specified it defaults to
> project.build.sourceEncoding, thus keeping the current behavior of the plugin
> unchanged.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7452) Remove JDK7 run on Maven 3.9.X Branch
[ https://issues.apache.org/jira/browse/MNG-7452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518657#comment-17518657 ] Hudson commented on MNG-7452: - Build succeeded in Jenkins: Maven » Maven TLP » maven » maven-3.9.x #11 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.9.x/11/ > Remove JDK7 run on Maven 3.9.X Branch > - > > Key: MNG-7452 > URL: https://issues.apache.org/jira/browse/MNG-7452 > Project: Maven > Issue Type: Task >Affects Versions: 3.9.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.9.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7433) [REGRESSION] Multiple maven instances working on same source tree can lock each other
[ https://issues.apache.org/jira/browse/MNG-7433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518656#comment-17518656 ] Dan Tran commented on MNG-7433: --- [~cstamas] thanks for the advice. In my use case i have 2 MVN each of course has its JVM. SuSE Linux +java11 OpenJDK from Amazon. This is definitely a very weird lockup issue > [REGRESSION] Multiple maven instances working on same source tree can lock > each other > - > > Key: MNG-7433 > URL: https://issues.apache.org/jira/browse/MNG-7433 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Dan Tran >Priority: Major > > I have a large multi modules java maven build where: > * phase 1 - basic build + unit tests + jacoco - 40 min > * phase 2 - sonar:sonar 20 min > * phase 3 - final packaging and basic smoke-test - 20 min > To take advantage of Maven multi-threaded build, during the reactor build, > one of our maven module spins another instance of Maven to run sonar:sonar > goal right after the basic build is done. > This means our phase 2 and phase 3 run in parallel sharing the same source > tree, same local maven repo (where sonar:sonar should have all needed > dependencies at the share local maven repo to run its task) > With maven-3.8.5, parallelization is no longer possible, phase 3 is blocked > until phase 2 is done. > I am able to trace it to https://github.com/apache/maven/pull/628 where the > locking started the happen > How does the lock mechanic work? there must be a local file where both Maven > instances are watching each other. Is there an option to disable this lock? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] michael-o commented on pull request #695: [MNG-7432] Dependencies from profile not picked up via -P
michael-o commented on PR #695: URL: https://github.com/apache/maven/pull/695#issuecomment-1091200127 > As I commented on JIRA, I consider the reproducer WRONG USECASE, and if we lift that into ITs we would put it in concrete... I go with that explanation -- 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-2063) Adding configuration using with --add-opens or --add-exports fails
[
https://issues.apache.org/jira/browse/SUREFIRE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518645#comment-17518645
]
Maarten Mulders commented on SUREFIRE-2063:
---
Maybe pointing out the obvious, but could it be related to this warning?
{code}
WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
{code}
> Adding configuration using with --add-opens or --add-exports fails
>
>
> Key: SUREFIRE-2063
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2063
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Daniel Subelman
>Priority: Major
>
> Since v3.3.0-M6 fails when using to export or open a package. The
> failure is produced when using --add-opens or --add-exports in .
> The execution doesn't fail with v3.3.0-M5 or earlier.
> As an example, it fails when using the following :
> {code:java}
>
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
>
> {code}
> The failure log:
> {code:java}
> [INFO] --- maven-surefire-plugin:3.0.0-M6:test (dev) @ testing ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
> Error: Could not find or load main class --add-opens
> Caused by: java.lang.ClassNotFoundException: --add-opens
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 9.157 s
> [INFO] Finished at: 2022-04-06T16:28:23-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (dev) on project
> testing:
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MNG-7452) Remove JDK7 run on Maven 3.9.X Branch
[ https://issues.apache.org/jira/browse/MNG-7452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MNG-7452. Resolution: Fixed > Remove JDK7 run on Maven 3.9.X Branch > - > > Key: MNG-7452 > URL: https://issues.apache.org/jira/browse/MNG-7452 > Project: Maven > Issue Type: Task >Affects Versions: 3.9.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.9.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7452) Remove JDK7 run on Maven 3.9.X Branch
[ https://issues.apache.org/jira/browse/MNG-7452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518644#comment-17518644 ] Karl Heinz Marbaise commented on MNG-7452: -- Done with a116f25002a0f5bb348a5416efd76e63ac54eb34 (maven-3.9.x) > Remove JDK7 run on Maven 3.9.X Branch > - > > Key: MNG-7452 > URL: https://issues.apache.org/jira/browse/MNG-7452 > Project: Maven > Issue Type: Task >Affects Versions: 3.9.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.9.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] asfgit merged pull request #707: [MNG-7452] - Remove JDK7 run on Maven 3.9.X Branch
asfgit merged PR #707: URL: https://github.com/apache/maven/pull/707 -- 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] cstamas commented on pull request #695: [MNG-7432] Dependencies from profile not picked up via -P
cstamas commented on PR #695: URL: https://github.com/apache/maven/pull/695#issuecomment-1091179586 As I commented on JIRA, I consider the reproducer WRONG USECASE, and if we lift that into ITs we would put it in concrete... -- 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] michael-o commented on pull request #695: [MNG-7432] Dependencies from profile not picked up via -P
michael-o commented on PR #695: URL: https://github.com/apache/maven/pull/695#issuecomment-1091174156 > Ok, but IMHO no need for IT here, as UT covers nicely (again: when resolver runs "within maven", the session.workspaceReader MUST be instanceof MavenWorkspaceReader to get expected -- stuff from reactor -- result, that's all) So, you even wouldn't consider to absorb the reproducer as an 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
[jira] [Closed] (MSKINS-176) That Will Be Permalink As Well Done Bellow At Look
[ https://issues.apache.org/jira/browse/MSKINS-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Mulders closed MSKINS-176. -- Resolution: Invalid > That Will Be Permalink As Well Done Bellow At Look > -- > > Key: MSKINS-176 > URL: https://issues.apache.org/jira/browse/MSKINS-176 > Project: Maven Skins > Issue Type: Bug > Components: Fluido Skin >Affects Versions: default-1.3, fluido-1.3.1, fluido-1.6, fluido-1.8 > Environment: Runners More Wait That Was Belong Of That Was I No More > Happy But away Are Trown own effect Are Bellow As Trips >Reporter: Swarup Patra >Priority: Minor > Labels: performance > Attachments: Screenshot_2022_0407_110912.png > > Original Estimate: 3,581h > Remaining Estimate: 3,581h > > That Will Be For Match Are Grow Up At Down More Looping At Sences That Will > Ready Us Called More Trips Are Belong That Was Troops Version Are Blood > Grought Complete Down Of Occos Are Looking More During Us Left Are More > Lighty Block More Success Figure That Was Left Are Brown Goal That Trips > Called More Down Runs That Way A Complete Ocvors Velocity Success During > Called Us More Rver Trips That Will Tooks Pond Questions Tolled Freelt Even > Buffer As Tooked Lokking Up Great Facualty Urban Trips That More Long Way > Havven No More Looking Us Craplote Upmaritions Yearly Takes More Lite Ly As > Figure Weed Have More Shortly Tht Was Copy Path Even More Looking Us Belong > As propratics That Remember Qre Head Or Body No More Left Us Hover That Was a > Block Peer To Long Read More Away Belong That Was Are Xcity. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MNG-7432) [REGRESSION] Dependencies from profile not picked up via -P
[ https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák updated MNG-7432: - Fix Version/s: 3.8.6 > [REGRESSION] Dependencies from profile not picked up via -P > > > Key: MNG-7432 > URL: https://issues.apache.org/jira/browse/MNG-7432 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Falko Modler >Priority: Critical > Fix For: 3.8.6 > > > The README of the following reproducer says it all: > https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation > Initially discussed here: > https://github.com/quarkusio/quarkus/pull/24285#issuecomment-1067368625 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (MNG-7433) [REGRESSION] Multiple maven instances working on same source tree can lock each other
[ https://issues.apache.org/jira/browse/MNG-7433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518625#comment-17518625 ] Tamás Cservenák edited comment on MNG-7433 at 4/7/22 7:03 AM: -- In that PR there is only in-JVM locking involved, there is no way that PR causes that multiple Maven instances (running in different JVMs) locks up each other. How do you run maven exactly? As "usual" so each maven spins up it's own JVM? What JVM you use? What OS you use? was (Author: cstamas): In that PR there is only in-JVM locking involved, there is no way that PR causes that multiple Maven instances (running in different JVMs) locks up each other. How do you run maven exactly? As "usual" so each maven spins up it's own JVM? What JVM you use? > [REGRESSION] Multiple maven instances working on same source tree can lock > each other > - > > Key: MNG-7433 > URL: https://issues.apache.org/jira/browse/MNG-7433 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Dan Tran >Priority: Major > > I have a large multi modules java maven build where: > * phase 1 - basic build + unit tests + jacoco - 40 min > * phase 2 - sonar:sonar 20 min > * phase 3 - final packaging and basic smoke-test - 20 min > To take advantage of Maven multi-threaded build, during the reactor build, > one of our maven module spins another instance of Maven to run sonar:sonar > goal right after the basic build is done. > This means our phase 2 and phase 3 run in parallel sharing the same source > tree, same local maven repo (where sonar:sonar should have all needed > dependencies at the share local maven repo to run its task) > With maven-3.8.5, parallelization is no longer possible, phase 3 is blocked > until phase 2 is done. > I am able to trace it to https://github.com/apache/maven/pull/628 where the > locking started the happen > How does the lock mechanic work? there must be a local file where both Maven > instances are watching each other. Is there an option to disable this lock? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7433) [REGRESSION] Multiple maven instances working on same source tree can lock each other
[ https://issues.apache.org/jira/browse/MNG-7433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518625#comment-17518625 ] Tamás Cservenák commented on MNG-7433: -- In that PR there is only in-JVM locking involved, there is no way that PR causes that multiple Maven instances (running in different JVMs) locks up each other. How do you run maven exactly? As "usual" so each maven spins up it's own JVM? What JVM you use? > [REGRESSION] Multiple maven instances working on same source tree can lock > each other > - > > Key: MNG-7433 > URL: https://issues.apache.org/jira/browse/MNG-7433 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Dan Tran >Priority: Major > > I have a large multi modules java maven build where: > * phase 1 - basic build + unit tests + jacoco - 40 min > * phase 2 - sonar:sonar 20 min > * phase 3 - final packaging and basic smoke-test - 20 min > To take advantage of Maven multi-threaded build, during the reactor build, > one of our maven module spins another instance of Maven to run sonar:sonar > goal right after the basic build is done. > This means our phase 2 and phase 3 run in parallel sharing the same source > tree, same local maven repo (where sonar:sonar should have all needed > dependencies at the share local maven repo to run its task) > With maven-3.8.5, parallelization is no longer possible, phase 3 is blocked > until phase 2 is done. > I am able to trace it to https://github.com/apache/maven/pull/628 where the > locking started the happen > How does the lock mechanic work? there must be a local file where both Maven > instances are watching each other. Is there an option to disable this lock? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] cstamas closed pull request #706: [MNG-7432] Proposed UT for maven-3.9.x and 3.8.x
cstamas closed pull request #706: [MNG-7432] Proposed UT for maven-3.9.x and 3.8.x URL: https://github.com/apache/maven/pull/706 -- 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] (MSKINS-176) That Will Be Permalink As Well Done Bellow At Look
Swarup Patra created MSKINS-176: --- Summary: That Will Be Permalink As Well Done Bellow At Look Key: MSKINS-176 URL: https://issues.apache.org/jira/browse/MSKINS-176 Project: Maven Skins Issue Type: Bug Components: Fluido Skin Affects Versions: fluido-1.8, fluido-1.6, fluido-1.3.1, default-1.3 Environment: Runners More Wait That Was Belong Of That Was I No More Happy But away Are Trown own effect Are Bellow As Trips Reporter: Swarup Patra Attachments: Screenshot_2022_0407_110912.png That Will Be For Match Are Grow Up At Down More Looping At Sences That Will Ready Us Called More Trips Are Belong That Was Troops Version Are Blood Grought Complete Down Of Occos Are Looking More During Us Left Are More Lighty Block More Success Figure That Was Left Are Brown Goal That Trips Called More Down Runs That Way A Complete Ocvors Velocity Success During Called Us More Rver Trips That Will Tooks Pond Questions Tolled Freelt Even Buffer As Tooked Lokking Up Great Facualty Urban Trips That More Long Way Havven No More Looking Us Craplote Upmaritions Yearly Takes More Lite Ly As Figure Weed Have More Shortly Tht Was Copy Path Even More Looking Us Belong As propratics That Remember Qre Head Or Body No More Left Us Hover That Was a Block Peer To Long Read More Away Belong That Was Are Xcity. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] cstamas commented on pull request #695: [MNG-7432] Dependencies from profile not picked up via -P
cstamas commented on PR #695: URL: https://github.com/apache/maven/pull/695#issuecomment-1091130425 Ok, but IMHO no need for IT here, as UT covers nicely (again: when resolver runs "within maven", the session.workspaceReader MUST be instanceof MavenWorkspaceReader to get expected -- stuff from reactor -- result, that's all) -- 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] michael-o commented on pull request #161: [MRESOLVER-248] Make BF and DF collectors coexists
michael-o commented on PR #161: URL: https://github.com/apache/maven-resolver/pull/161#issuecomment-1091128321 Will review today/tomorrow. -- 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] michael-o commented on pull request #695: [MNG-7432] Dependencies from profile not picked up via -P
michael-o commented on PR #695: URL: https://github.com/apache/maven/pull/695#issuecomment-1091128011 Feel free to take over the entire ticket handling with IT, etc. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MARTIFACT-24) add artifact:check-buildplan goal to check that plugins versions do not have known reproducibility issues
[ https://issues.apache.org/jira/browse/MARTIFACT-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MARTIFACT-24: --- Summary: add artifact:check-buildplan goal to check that plugins versions do not have known reproducibility issues (was: add goal to check that plugins versions do not have known reproducibility issues) > add artifact:check-buildplan goal to check that plugins versions do not have > known reproducibility issues > - > > Key: MARTIFACT-24 > URL: https://issues.apache.org/jira/browse/MARTIFACT-24 > Project: Maven Artifact Plugin > Issue Type: New Feature > Components: artifact:buildinfo, artifact:compare >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.3.0 > > > for newbies wanting to make their build reproducible, having a first analysis > of what to fix in their pom.xml would ease a lot: we have a list of known > plugins with minimal versions -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-resolver] cstamas commented on pull request #161: [MRESOLVER-248] Make BF and DF collectors coexists
cstamas commented on PR #161: URL: https://github.com/apache/maven-resolver/pull/161#issuecomment-1091126958 @caiwei-ebay all looking good here? Any proposal to change/add? -- 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] cstamas commented on pull request #161: [MRESOLVER-248] Make BF and DF collectors coexists
cstamas commented on PR #161: URL: https://github.com/apache/maven-resolver/pull/161#issuecomment-1091126697 @michael-o any blocker here? -- 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
