[GitHub] [maven-jar-plugin] dependabot[bot] closed pull request #38: Bump release-drafter/release-drafter from 5.18.1 to 5.20.0
dependabot[bot] closed pull request #38: Bump release-drafter/release-drafter from 5.18.1 to 5.20.0 URL: https://github.com/apache/maven-jar-plugin/pull/38 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jar-plugin] dependabot[bot] opened a new pull request, #39: Bump junit from 4.11 to 4.13.1 in /src/it/MJAR-228
dependabot[bot] opened a new pull request, #39: URL: https://github.com/apache/maven-jar-plugin/pull/39 Bumps [junit](https://github.com/junit-team/junit4) from 4.11 to 4.13.1. Release notes Sourced from https://github.com/junit-team/junit4/releases;>junit's releases. JUnit 4.13.1 Please refer to the https://github.com/junit-team/junit/blob/HEAD/doc/ReleaseNotes4.13.1.md;>release notes for details. JUnit 4.13 Please refer to the https://github.com/junit-team/junit/blob/HEAD/doc/ReleaseNotes4.13.md;>release notes for details. JUnit 4.13 RC 2 Please refer to the https://github.com/junit-team/junit4/wiki/4.13-Release-Notes;>release notes for details. JUnit 4.13 RC 1 Please refer to the https://github.com/junit-team/junit4/wiki/4.13-Release-Notes;>release notes for details. JUnit 4.13 Beta 3 Please refer to the https://github.com/junit-team/junit4/wiki/4.13-Release-Notes;>release notes for details. JUnit 4.13 Beta 2 Please refer to the https://github.com/junit-team/junit4/wiki/4.13-Release-Notes;>release notes for details. JUnit 4.13 Beta 1 Please refer to the https://github.com/junit-team/junit4/wiki/4.13-Release-Notes;>release notes for details. JUnit 4.12 Please refer to the https://github.com/junit-team/junit/blob/HEAD/doc/ReleaseNotes4.12.md;>release notes for details. JUnit 4.12 Beta 3 Please refer to the https://github.com/junit-team/junit/blob/HEAD/doc/ReleaseNotes4.12.md;>release notes for details. JUnit 4.12 Beta 2 No release notes provided. JUnit 4.12 Beta 1 No release notes provided. Commits https://github.com/junit-team/junit4/commit/1b683f4ec07bcfa40149f086d32240f805487e66;>1b683f4 [maven-release-plugin] prepare release r4.13.1 https://github.com/junit-team/junit4/commit/ce6ce3aadc070db2902698fe0d3dc6729cd631f2;>ce6ce3a Draft 4.13.1 release notes https://github.com/junit-team/junit4/commit/c29dd8239d6b353e699397eb090a1fd27411fa24;>c29dd82 Change version to 4.13.1-SNAPSHOT https://github.com/junit-team/junit4/commit/1d174861f0b64f97ab0722bb324a760bfb02f567;>1d17486 Add a link to assertThrows in exception testing https://github.com/junit-team/junit4/commit/543905df72ff10364b94dda27552efebf3dd04e9;>543905d Use separate line for annotation in Javadoc https://github.com/junit-team/junit4/commit/510e906b391e7e46a346e1c852416dc7be934944;>510e906 Add sub headlines to class Javadoc https://github.com/junit-team/junit4/commit/610155b8c22138329f0723eec22521627dbc52ae;>610155b Merge pull request from GHSA-269g-pwp5-87pp https://github.com/junit-team/junit4/commit/b6cfd1e3d736cc2106242a8be799615b472c7fec;>b6cfd1e Explicitly wrap float parameter for consistency (https://github-redirect.dependabot.com/junit-team/junit4/issues/1671;>#1671) https://github.com/junit-team/junit4/commit/a5d205c7956dbed302b3bb5ecde5ba4299f0b646;>a5d205c Fix GitHub link in FAQ (https://github-redirect.dependabot.com/junit-team/junit4/issues/1672;>#1672) https://github.com/junit-team/junit4/commit/3a5c6b4d08f408c8ca6a8e0bae71a9bc5a8f97e8;>3a5c6b4 Deprecated since jdk9 replacing constructor instance of Double and Float (https://github-redirect.dependabot.com/junit-team/junit4/issues/1660;>#1660) Additional commits viewable in https://github.com/junit-team/junit4/compare/r4.11...r4.13.1;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (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
[GitHub] [maven-jar-plugin] dependabot[bot] commented on pull request #38: Bump release-drafter/release-drafter from 5.18.1 to 5.20.0
dependabot[bot] commented on PR #38: URL: https://github.com/apache/maven-jar-plugin/pull/38#issuecomment-1124548819 Looks like release-drafter/release-drafter is no longer a dependency, so this is no longer needed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-gh-actions-shared] slawekjaranowski merged pull request #43: Bump release-drafter/release-drafter from 5.19.0 to 5.20.0
slawekjaranowski merged PR #43: URL: https://github.com/apache/maven-gh-actions-shared/pull/43 -- 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-gh-actions-shared] dependabot[bot] opened a new pull request, #43: Bump release-drafter/release-drafter from 5.19.0 to 5.20.0
dependabot[bot] opened a new pull request, #43: URL: https://github.com/apache/maven-gh-actions-shared/pull/43 Bumps [release-drafter/release-drafter](https://github.com/release-drafter/release-drafter) from 5.19.0 to 5.20.0. Release notes Sourced from https://github.com/release-drafter/release-drafter/releases;>release-drafter/release-drafter's releases. v5.20.0 What's Changed New allow header and footer to be passed as input (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1142;>#1142) https://github.com/jetersen;>@jetersen Dependency Updates Bump jest from 27.5.1 to 28.1.0 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1140;>#1140) https://github.com/dependabot;>@dependabot Bump eslint from 8.14.0 to 8.15.0 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1137;>#1137) https://github.com/dependabot;>@dependabot Bump @actions/core from 1.6.0 to 1.8.0 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1139;>#1139) https://github.com/dependabot;>@dependabot Bump lint-staged from 12.4.0 to 12.4.1 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1131;>#1131) https://github.com/dependabot;>@dependabot Bump @actions/core from 1.6.0 to 1.7.0 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1129;>#1129) https://github.com/dependabot;>@dependabot Bump husky from 7.0.4 to 8.0.0 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1138;>#1138) https://github.com/dependabot;>@dependabot Bump eslint from 8.13.0 to 8.14.0 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1127;>#1127) https://github.com/dependabot;>@dependabot Bump cli-table3 from 0.6.1 to 0.6.2 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1122;>#1122) https://github.com/dependabot;>@dependabot Bump node from 17.8.0-alpine to 17.9.0-alpine (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1121;>#1121) https://github.com/dependabot;>@dependabot Bump semver from 7.3.6 to 7.3.7 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1120;>#1120) https://github.com/dependabot;>@dependabot Bump @vercel/ncc from 0.33.3 to 0.33.4 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1118;>#1118) https://github.com/dependabot;>@dependabot Bump lint-staged from 12.3.7 to 12.4.0 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1124;>#1124) https://github.com/dependabot;>@dependabot Bump eslint from 8.11.0 to 8.13.0 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1117;>#1117) https://github.com/dependabot;>@dependabot Bump semver from 7.3.5 to 7.3.6 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1115;>#1115) https://github.com/dependabot;>@dependabot Bump eslint-plugin-unicorn from 41.0.1 to 42.0.0 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1113;>#1113) https://github.com/dependabot;>@dependabot Bump prettier from 2.6.0 to 2.6.2 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1112;>#1112) https://github.com/dependabot;>@dependabot Bump node from 17.7.1-alpine to 17.8.0-alpine (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1108;>#1108) https://github.com/dependabot;>@dependabot Bump minimist from 1.2.5 to 1.2.6 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1116;>#1116) https://github.com/dependabot;>@dependabot Bump lint-staged from 12.3.6 to 12.3.7 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1104;>#1104) https://github.com/dependabot;>@dependabot Bump eslint-plugin-unicorn from 41.0.0 to 41.0.1 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1105;>#1105) https://github.com/dependabot;>@dependabot Bump node from 8c62619 to d1d5dc5 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1106;>#1106) https://github.com/dependabot;>@dependabot Bump probot from 12.2.1 to 12.2.2 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1097;>#1097) https://github.com/dependabot;>@dependabot Bump node from 17.6.0-alpine to 17.7.1-alpine (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1100;>#1100) https://github.com/dependabot;>@dependabot Bump eslint from 8.10.0 to 8.11.0 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1099;>#1099) https://github.com/dependabot;>@dependabot Bump prettier from 2.5.1 to 2.6.0
[GitHub] [maven-jar-plugin] dependabot[bot] closed pull request #33: Bump release-drafter/release-drafter from 5.18.1 to 5.19.0
dependabot[bot] closed pull request #33: Bump release-drafter/release-drafter from 5.18.1 to 5.19.0 URL: https://github.com/apache/maven-jar-plugin/pull/33 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jar-plugin] dependabot[bot] commented on pull request #33: Bump release-drafter/release-drafter from 5.18.1 to 5.19.0
dependabot[bot] commented on PR #33: URL: https://github.com/apache/maven-jar-plugin/pull/33#issuecomment-1124463134 Superseded by #38. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jar-plugin] dependabot[bot] opened a new pull request, #38: Bump release-drafter/release-drafter from 5.18.1 to 5.20.0
dependabot[bot] opened a new pull request, #38: URL: https://github.com/apache/maven-jar-plugin/pull/38 Bumps [release-drafter/release-drafter](https://github.com/release-drafter/release-drafter) from 5.18.1 to 5.20.0. Release notes Sourced from https://github.com/release-drafter/release-drafter/releases;>release-drafter/release-drafter's releases. v5.20.0 What's Changed New allow header and footer to be passed as input (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1142;>#1142) https://github.com/jetersen;>@jetersen Dependency Updates Bump jest from 27.5.1 to 28.1.0 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1140;>#1140) https://github.com/dependabot;>@dependabot Bump eslint from 8.14.0 to 8.15.0 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1137;>#1137) https://github.com/dependabot;>@dependabot Bump @actions/core from 1.6.0 to 1.8.0 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1139;>#1139) https://github.com/dependabot;>@dependabot Bump lint-staged from 12.4.0 to 12.4.1 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1131;>#1131) https://github.com/dependabot;>@dependabot Bump @actions/core from 1.6.0 to 1.7.0 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1129;>#1129) https://github.com/dependabot;>@dependabot Bump husky from 7.0.4 to 8.0.0 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1138;>#1138) https://github.com/dependabot;>@dependabot Bump eslint from 8.13.0 to 8.14.0 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1127;>#1127) https://github.com/dependabot;>@dependabot Bump cli-table3 from 0.6.1 to 0.6.2 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1122;>#1122) https://github.com/dependabot;>@dependabot Bump node from 17.8.0-alpine to 17.9.0-alpine (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1121;>#1121) https://github.com/dependabot;>@dependabot Bump semver from 7.3.6 to 7.3.7 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1120;>#1120) https://github.com/dependabot;>@dependabot Bump @vercel/ncc from 0.33.3 to 0.33.4 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1118;>#1118) https://github.com/dependabot;>@dependabot Bump lint-staged from 12.3.7 to 12.4.0 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1124;>#1124) https://github.com/dependabot;>@dependabot Bump eslint from 8.11.0 to 8.13.0 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1117;>#1117) https://github.com/dependabot;>@dependabot Bump semver from 7.3.5 to 7.3.6 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1115;>#1115) https://github.com/dependabot;>@dependabot Bump eslint-plugin-unicorn from 41.0.1 to 42.0.0 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1113;>#1113) https://github.com/dependabot;>@dependabot Bump prettier from 2.6.0 to 2.6.2 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1112;>#1112) https://github.com/dependabot;>@dependabot Bump node from 17.7.1-alpine to 17.8.0-alpine (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1108;>#1108) https://github.com/dependabot;>@dependabot Bump minimist from 1.2.5 to 1.2.6 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1116;>#1116) https://github.com/dependabot;>@dependabot Bump lint-staged from 12.3.6 to 12.3.7 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1104;>#1104) https://github.com/dependabot;>@dependabot Bump eslint-plugin-unicorn from 41.0.0 to 41.0.1 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1105;>#1105) https://github.com/dependabot;>@dependabot Bump node from 8c62619 to d1d5dc5 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1106;>#1106) https://github.com/dependabot;>@dependabot Bump probot from 12.2.1 to 12.2.2 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1097;>#1097) https://github.com/dependabot;>@dependabot Bump node from 17.6.0-alpine to 17.7.1-alpine (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1100;>#1100) https://github.com/dependabot;>@dependabot Bump eslint from 8.10.0 to 8.11.0 (https://github-redirect.dependabot.com/release-drafter/release-drafter/issues/1099;>#1099) https://github.com/dependabot;>@dependabot Bump prettier from 2.5.1 to 2.6.0
[GitHub] [maven-integration-testing] olamy commented on pull request #147: Bump jetty-server from 9.0.4.v20130625 to 9.4.41.v20210516 in /core-it-suite
olamy commented on PR #147: URL: https://github.com/apache/maven-integration-testing/pull/147#issuecomment-1124451103 maybe time to be java 8? quick note even jetty 9.4.x will EOL really soon https://www.eclipse.org//lists/jetty-announce/msg00168.html -- 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 pull request #531: [SUREFIRE-2082] - Close file handles asap to prevent breaching the system's maximum number of open files
Tibor17 commented on PR #531: URL: https://github.com/apache/maven-surefire/pull/531#issuecomment-1124407880 Here are my changes #534, we can talk about it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-doxia-sitetools] dependabot[bot] closed pull request #34: Bump htmlunit from 2.24 to 2.60.0
dependabot[bot] closed pull request #34: Bump htmlunit from 2.24 to 2.60.0 URL: https://github.com/apache/maven-doxia-sitetools/pull/34 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-doxia-sitetools] dependabot[bot] commented on pull request #34: Bump htmlunit from 2.24 to 2.60.0
dependabot[bot] commented on PR #34: URL: https://github.com/apache/maven-doxia-sitetools/pull/34#issuecomment-1124405194 Superseded by #40. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-doxia-sitetools] dependabot[bot] opened a new pull request, #40: Bump htmlunit from 2.24 to 2.61.0
dependabot[bot] opened a new pull request, #40: URL: https://github.com/apache/maven-doxia-sitetools/pull/40 Bumps [htmlunit](https://github.com/HtmlUnit/htmlunit) from 2.24 to 2.61.0. Release notes Sourced from https://github.com/HtmlUnit/htmlunit/releases;>htmlunit's releases. HtmlUnit 2.61.0 Chrome/Edge 100 Firefox 99 Bugfixes Enhancements neko: Possilbe OOM exception with broken input fixed use NativeConsole from core-js instead of our own implementation INCOMPATIBLE CHANGE: Class MediaList was moved from package com.gargoylesoftware.htmlunit.javascript.host.dom into package com.gargoylesoftware.htmlunit.javascript.host.css new method WebRequest.getParameters() returning all parameters (from the url and the body if available). This change was required to fix some issues with Spring MockMVC. Please have a look at the https://htmlunit.sourceforge.io/changes-report.html#a2.61.0;>full release notes for details about this release. :two_hearts: Thank you to all who have contributed and to the sponsors (more sponsoring is welcome https://t.co/mmX3kAlCXy;>https://github.com/sponsors/rbri). HtmlUnit 2.60.0 Chrome/Edge 99 Bugfixes fix broken package-info files generated by the maven plugin used for version 2.59.0 (see https://github-redirect.dependabot.com/HtmlUnit/htmlunit/issues/457;>HtmlUnit/htmlunit#457) Please have a look at the https://htmlunit.sourceforge.io/changes-report.html#a2.60.0;>full release notes for details about this release. HtmlUnit 2.59.0 Chrome/Edge 98 Firefox 97 Polyfills for Fetch and Proxy ClipboardHandler Rhino updates Bugfixes dedicated documentation of the WebClient/WebClientOptions Please have a look at the https://htmlunit.sourceforge.io/changes-report.html#a2.59.0;>full release notes for details about this release. HtmlUnit 2.58.0 bunch of Rhino updates client side validation fixes SimpleScriptable is deprecated, please use HtmlUnitScriptable instead Please have a look at the https://htmlunit.sourceforge.io/changes-report.html#a2.58.0;>full release notes for details about this release. HtmlUnit 2.57.0 Chrome/Edge 97 Firefox 96 ValidityState implemented htmx support Please have a look at the https://htmlunit.sourceforge.io/changes-report.html#a2.57.0;>full release notes for details about this release. HtmlUnit 2.56.0 Highlights Chrome/Edge 96 Firefox 95 ... (truncated) Commits https://github.com/HtmlUnit/htmlunit/commit/ad5208c22fda11c065330f7ba2dd97a89a1a0371;>ad5208c prepare 2.61.0 https://github.com/HtmlUnit/htmlunit/commit/68aede93bfe40409e0023389d4fa3e0cf4daca6e;>68aede9 core-js 2.61.1 https://github.com/HtmlUnit/htmlunit/commit/a7d65d735168f923c636476245b149f7d1eeb444;>a7d65d7 core-js 2.61.0 https://github.com/HtmlUnit/htmlunit/commit/6ce606c912eb1d05da26e60c83ae32c07399f379;>6ce606c use cssparser 1.12.0 https://github.com/HtmlUnit/htmlunit/commit/eaaf14a249924ec73fab11910faa1ac36cddad45;>eaaf14a String.toLocaleLowerCase() takes care of provided locale https://github.com/HtmlUnit/htmlunit/commit/9d273a0dce22daf3304370608c12d8b63c49ddf6;>9d273a0 fix test https://github.com/HtmlUnit/htmlunit/commit/94c13e3cf2a01eee6ba0a8d43c7ec30391fd080d;>94c13e3 htmx 1.7.0 is working https://github.com/HtmlUnit/htmlunit/commit/c5ebfef3f866b7ce2416d67fc13a73fba246095b;>c5ebfef fix test https://github.com/HtmlUnit/htmlunit/commit/662d506271cbe06139415112c5eee053c7b72386;>662d506 dependency-check update https://github.com/HtmlUnit/htmlunit/commit/9fd8803ae608e82588a83dde25c75c2f7128563d;>9fd8803 Input formNoValidate propery added Additional commits viewable in https://github.com/HtmlUnit/htmlunit/compare/HtmlUnit-2.24...2.61.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
[GitHub] [maven-shade-plugin] slachiewicz commented on pull request #116: Bump plexus-utils from 3.3.0 to 3.4.1
slachiewicz commented on PR #116: URL: https://github.com/apache/maven-shade-plugin/pull/116#issuecomment-1124400099 @dependabot rebase -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-shade-plugin] slachiewicz commented on pull request #125: Bump xmlunit-legacy from 2.7.0 to 2.9.0
slachiewicz commented on PR #125: URL: https://github.com/apache/maven-shade-plugin/pull/125#issuecomment-1124398962 @dependabot rebase -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] slachiewicz merged pull request #147: Bump maven-javadoc-plugin from 3.3.1 to 3.4.0
slachiewicz merged PR #147: URL: https://github.com/apache/maven-enforcer/pull/147 -- 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-enforcer] slachiewicz merged pull request #148: Bump maven-surefire-plugin from 3.0.0-M5 to 3.0.0-M6
slachiewicz merged PR #148: URL: https://github.com/apache/maven-enforcer/pull/148 -- 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-7475) [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in FileProfileActivator.setPathTranslator()
[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17535131#comment-17535131
]
Andreas Loew commented on MNG-7475:
---
Sorry, but whom do you, Tamás, refer to when saying: "{+}**You**{+} are
misusing..."
It's not "me"... I am just an ordinary end user - and my customer, my team and
myself are simply using Red Hat commercial JBoss together with Arquillian suite
code to run and unit/integration test our legacy Java EE applications.
So I +**do not**+ have any chance to modify Red Hat's code (well, other than
possibly forking its Git repo myself and updating my fork, if all other
attempts fail), and sadly, the Arquillian code is no longer maintained by Red
Hat...
*I wouldn't think it is good practice or appropriate from the Maven side to
change a* *public API,* *publicly documented with officially published
Javadocs, six years later in a minor dot release, without any previous
deprecation or public notice - and then telling end users that a company like
Red Hat simply used your API the completely wrong way back in 2016.*
Are you sure that this even clearly was a "managed component" back in 2016 when
Maven version 3.3.9 was current? Why had its setter method been made public at
all back then if this were the case? And in case it indeed already was a
managed component in Maven 3.3.9, then the mistake is also on the Maven side,
as the code then should never have been written with a public setter method the
way it used to be for 6 years until the most recent change.
Sorry, but please don't try to duck out of a clear mistake on the Maven side
here, namely breaking binary compatibility. When you do some refactorings on
your widely used codebase, fine, but not at the cost of breaking a public API
in this way.
Please let's try to think about some less "negative" approach: *Why not try and
focus on finding a meaningful way to stay with your new concept of a managed
component, but still implement/wrap/map the missing method in order to still
support and not break the published API...*
Shouldn't it be possible to keep binary compatibility on the Maven side by
still providing the old API (i.e. the old public method and the old class used
as a parameter) but do so by properly wrapping/mapping it to the correct, new
implementation?
Many thanks for listening! ;)
> [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in
> FileProfileActivator.setPathTranslator()
> -
>
> Key: MNG-7475
> URL: https://issues.apache.org/jira/browse/MNG-7475
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.8.5
> Environment: any & deterministically reproducible / proven by public
> API docs
>Reporter: Andreas Loew
>Priority: Major
>
> Maven 3.8.5 breaks [Arquillian
> ShrinkWrap|https://arquillian.org/modules/shrinkwrap-shrinkwrap] (and
> thereby, most if not all use of Red Hat/JBoss Arquillian) by changing the
> published public API of class
> org.apache.maven.model.profile.activation.FileProfileActivator:
> {code:java}
> [ERROR]
> com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest
> Time elapsed: 0.127 s <<< ERROR!
> java.lang.NoSuchMethodError:
> 'org.apache.maven.model.profile.activation.FileProfileActivator
> org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
> at
> org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
> at
> org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
> at
> org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
> at
> org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
> at
> org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
> at
>
[GitHub] [maven-surefire] Tibor17 opened a new pull request, #534: [SUREFIRE-2082] Close file handles asap to prevent breaching the system's maximum number of open files
Tibor17 opened a new pull request, #534: URL: https://github.com/apache/maven-surefire/pull/534 Some explanation for #531 . 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] (MENFORCER-402) RequireUpperBoundDeps now follow scope provided transitive dependencies
[
https://issues.apache.org/jira/browse/MENFORCER-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17535129#comment-17535129
]
Matt Nelson commented on MENFORCER-402:
---
[~slachiewicz] I tried posting to the mailing list on this but I must've done
something wrong cause it never showed up. The request to release 3.0.1 was to
get MENFORCER-394 released which includes a fix identical to the one proposed
on the [PRhttps://github.com/apache/maven-enforcer/pull/140]. Would it be
possible to get that PR merged and included with 3.0.1?
https://lists.apache.org/thread/4y91thymlwfblhvfmfy1y9sg24xg2dhq
> RequireUpperBoundDeps now follow scope provided transitive dependencies
> ---
>
> Key: MENFORCER-402
> URL: https://issues.apache.org/jira/browse/MENFORCER-402
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.0.0
>Reporter: Thomas Mortagne
>Priority: Major
>
> I have a dependency on org.infinispan:infinispan-core:12.1.7.Final and
> upgrading to the enforcer plugin 3.0.0 suddenly made my module fail because
> infinispan-core have conflicting provided dependencies on
> javax.annotation-api:
> {noformat}
> Require upper bound dependencies error for
> javax.annotation:javax.annotation-api:1.3.1 [provided] paths to dependency
> are:
> +-org.xwiki.commons:xwiki-commons-cache-infinispan:13.9-SNAPSHOT
> +-org.infinispan:infinispan-core:12.1.7.Final
> +-javax.annotation:javax.annotation-api:1.3.1 [provided]
> and
> +-org.xwiki.commons:xwiki-commons-cache-infinispan:13.9-SNAPSHOT
> +-org.infinispan:infinispan-core:12.1.7.Final
> +-org.infinispan:infinispan-commons:12.1.7.Final
> +-javax.annotation:javax.annotation-api:1.3.1 [provided]
> and
> +-org.xwiki.commons:xwiki-commons-cache-infinispan:13.9-SNAPSHOT
> +-org.infinispan:infinispan-core:12.1.7.Final
> +-org.infinispan:infinispan-component-processor:12.1.7.Final [provided]
> +-javax.annotation:javax.annotation-api:1.3.1 [provided]
> and
> +-org.xwiki.commons:xwiki-commons-cache-infinispan:13.9-SNAPSHOT
> +-org.infinispan:infinispan-core:12.1.7.Final
> +-org.infinispan.protostream:protostream-types:4.4.1.Final
> +-javax.annotation:javax.annotation-api:1.3.2 [provided]
> and
> +-org.xwiki.commons:xwiki-commons-cache-infinispan:13.9-SNAPSHOT
> +-org.infinispan:infinispan-core:12.1.7.Final
> +-org.infinispan.protostream:protostream-processor:4.4.1.Final [provided]
> +-javax.annotation:javax.annotation-api:1.3.2 [provided]
> and
> +-org.xwiki.commons:xwiki-commons-cache-infinispan:13.9-SNAPSHOT
> +-org.infinispan:infinispan-core:12.1.7.Final
> +-org.infinispan:infinispan-commons:12.1.7.Final
> +-org.infinispan:infinispan-commons-jdk11:12.1.7.Final [provided]
> +-javax.annotation:javax.annotation-api:1.3.1 [provided]
> {noformat}
> It's not clear if this was done on purpose since I cannot find anything about
> that in the release note, but I might have missed it. Problem is that
> provided scope dependencies are not necessarily used at runtime (it's often
> used as a way to avoid making transitive a dependency you only need at build
> time) and adding an for a non-transitive dependency feels quite
> weird.
> At least if this is not a bug, it would be nice to make this behavior
> configurable.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-dependency-plugin] dependabot[bot] commented on pull request #209: Bump org.eclipse.sisu.inject from 0.0.0.M5 to 0.3.5
dependabot[bot] commented on PR #209: URL: https://github.com/apache/maven-dependency-plugin/pull/209#issuecomment-1124358854 Superseded by #216. -- 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-dependency-plugin] dependabot[bot] closed pull request #209: Bump org.eclipse.sisu.inject from 0.0.0.M5 to 0.3.5
dependabot[bot] closed pull request #209: Bump org.eclipse.sisu.inject from 0.0.0.M5 to 0.3.5 URL: https://github.com/apache/maven-dependency-plugin/pull/209 -- 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-dependency-plugin] dependabot[bot] opened a new pull request, #216: Bump org.eclipse.sisu.inject from 0.0.0.M5 to 0.9.0.M1
dependabot[bot] opened a new pull request, #216: URL: https://github.com/apache/maven-dependency-plugin/pull/216 Bumps [org.eclipse.sisu.inject](https://github.com/eclipse/sisu.inject) from 0.0.0.M5 to 0.9.0.M1. Release notes Sourced from https://github.com/eclipse/sisu.inject/releases;>org.eclipse.sisu.inject's releases. 0.9.0.M1 What's Changed Fix CDI related issues by https://github.com/cstamas;>@cstamas in https://github-redirect.dependabot.com/eclipse/sisu.inject/pull/1;>eclipse/sisu.inject#1 Build with Eclipse/Tycho 2.5.0 and Java 11 by https://github.com/mcculls;>@mcculls in https://github-redirect.dependabot.com/eclipse/sisu.inject/pull/33;>eclipse/sisu.inject#33 Raise problem reporting logs to DEBUG, fixes https://github-redirect.dependabot.com/eclipse/sisu.inject/issues/36;>#36 by https://github.com/gnodet;>@gnodet in https://github-redirect.dependabot.com/eclipse/sisu.inject/pull/37;>eclipse/sisu.inject#37 Upgrade internal copy of ASM to 9.2 by https://github.com/mcculls;>@mcculls in https://github-redirect.dependabot.com/eclipse/sisu.inject/pull/34;>eclipse/sisu.inject#34 Implement PathTypeConverter by https://github.com/mcculls;>@mcculls in https://github-redirect.dependabot.com/eclipse/sisu.inject/pull/39;>eclipse/sisu.inject#39 Add JUnit 5 annotations to InjectedTest setUp/tearDown by https://github.com/mcculls;>@mcculls in https://github-redirect.dependabot.com/eclipse/sisu.inject/pull/40;>eclipse/sisu.inject#40 Fix static parameters binding lookup by https://github.com/mcculls;>@mcculls in https://github-redirect.dependabot.com/eclipse/sisu.inject/pull/41;>eclipse/sisu.inject#41 Run injection tests against multiple versions of Guice by https://github.com/mcculls;>@mcculls in https://github-redirect.dependabot.com/eclipse/sisu.inject/pull/42;>eclipse/sisu.inject#42 Support using https://github.com/Priority;>@Priority on Providers by https://github.com/mcculls;>@mcculls in https://github-redirect.dependabot.com/eclipse/sisu.inject/pull/43;>eclipse/sisu.inject#43 Use read lock when subscribing to publishers… by https://github.com/mcculls;>@mcculls in https://github-redirect.dependabot.com/eclipse/sisu.inject/pull/44;>eclipse/sisu.inject#44 Cache binding lookups for single bean providers by https://github.com/mcculls;>@mcculls in https://github-redirect.dependabot.com/eclipse/sisu.inject/pull/45;>eclipse/sisu.inject#45 Use AtomicReferenceFieldUpdater as it works better for large numbers of instances by https://github.com/mcculls;>@mcculls in https://github-redirect.dependabot.com/eclipse/sisu.inject/pull/46;>eclipse/sisu.inject#46 Enable Java CI workflow by https://github.com/mcculls;>@mcculls in https://github-redirect.dependabot.com/eclipse/sisu.inject/pull/47;>eclipse/sisu.inject#47 Enable CodeQL analysis by https://github.com/mcculls;>@mcculls in https://github-redirect.dependabot.com/eclipse/sisu.inject/pull/48;>eclipse/sisu.inject#48 Replace potentially-expensive regex with simple tokenizer by https://github.com/mcculls;>@mcculls in https://github-redirect.dependabot.com/eclipse/sisu.inject/pull/49;>eclipse/sisu.inject#49 Allow Main to boot with extra bindings by https://github.com/bentmann;>@bentmann in https://github-redirect.dependabot.com/eclipse/sisu.inject/pull/50;>eclipse/sisu.inject#50 Re-enable various resource-related unit tests by https://github.com/mcculls;>@mcculls in https://github-redirect.dependabot.com/eclipse/sisu.inject/pull/51;>eclipse/sisu.inject#51 Rework globber pattern strategy to avoid use of regex by https://github.com/mcculls;>@mcculls in https://github-redirect.dependabot.com/eclipse/sisu.inject/pull/52;>eclipse/sisu.inject#52 Use GlobberStrategy.PATTERN instead of regex for ServiceBindings filtering by https://github.com/mcculls;>@mcculls in https://github-redirect.dependabot.com/eclipse/sisu.inject/pull/53;>eclipse/sisu.inject#53 New Contributors https://github.com/cstamas;>@cstamas made their first contribution in https://github-redirect.dependabot.com/eclipse/sisu.inject/pull/1;>eclipse/sisu.inject#1 https://github.com/gnodet;>@gnodet made their first contribution in https://github-redirect.dependabot.com/eclipse/sisu.inject/pull/37;>eclipse/sisu.inject#37 https://github.com/bentmann;>@bentmann made their first contribution in https://github-redirect.dependabot.com/eclipse/sisu.inject/pull/50;>eclipse/sisu.inject#50 Full Changelog: https://github.com/eclipse/sisu.inject/commits/milestones/0.9.0.M1;>https://github.com/eclipse/sisu.inject/commits/milestones/0.9.0.M1 0.3.5 Maintenance release Build against CDI API 1.2 Commits https://github.com/eclipse/sisu.inject/commit/3d1bc612d8c7de74ad937b9c41a18a2ce63bfec6;>3d1bc61 Milestone 0.9.0.M1 https://github.com/eclipse/sisu.inject/commit/cbeeac8395111d8ec27705b86ccadd8f576bbbe1;>cbeeac8 Only toggle tycho.extensions, keep
[GitHub] [maven] michael-o commented on pull request #735: Trasnport: use config properties instead user properties.
michael-o commented on PR #735: URL: https://github.com/apache/maven/pull/735#issuecomment-1124350714 No, at least not for now. It is a user feature therefore a user property -- 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 #735: Trasnport: use config properties instead user properties.
cstamas commented on PR #735: URL: https://github.com/apache/maven/pull/735#issuecomment-1124295612 Do we want to address build consumer feature as well? As it suffers from very same issue -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-integration-testing] cstamas commented on pull request #147: Bump jetty-server from 9.0.4.v20130625 to 9.4.41.v20210516 in /core-it-suite
cstamas commented on PR #147: URL: https://github.com/apache/maven-integration-testing/pull/147#issuecomment-1124293545 Nope, IT suite is still 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-integration-testing] cstamas commented on pull request #147: Bump jetty-server from 9.0.4.v20130625 to 9.4.41.v20210516 in /core-it-suite
cstamas commented on PR #147: URL: https://github.com/apache/maven-integration-testing/pull/147#issuecomment-1124289671 Nope, IT suite is still 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
[jira] [Resolved] (MDEP-804) Allow auto-ignore of all non-test scoped dependencies used only in test scope
[ https://issues.apache.org/jira/browse/MDEP-804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen resolved MDEP-804. - Fix Version/s: next-release (was: wontfix-candidate) Resolution: Fixed > Allow auto-ignore of all non-test scoped dependencies used only in test scope > - > > Key: MDEP-804 > URL: https://issues.apache.org/jira/browse/MDEP-804 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: analyze >Affects Versions: 3.3.0 >Reporter: Henning Schmiedehausen >Assignee: Henning Schmiedehausen >Priority: Major > Labels: pull-request-available > Fix For: next-release > > > Pre-3.2.0, dependencies that were used only in test scope but not declared in > test scope (most likely declared in compile scope) were accepted by the > plugin and not flagged as a problem. > Starting with 3.2.0 (and the current 3.3.0), these are reported with > "Non-test scoped test only dependencies found". If the scope of the > dependencies can not be changed (there are many reasons for that in large > projects), the old behavior can be restored by adding each flagged dependency > to the "ignoredNonTestScopedDependencies" configuration option in the > respective project. > This is, especially in large projects, cumbersome and brittle. > There should be a boolean flag, "ignoreAllNonTestScoped" that, when set, > allows ignoring non-test scoped dependencies if they are used only in test > scope. This flag restores the pre-3.2.0 behavior. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-integration-testing] cstamas merged pull request #158: [MNG-7470] mvn 3.9+ IT that uses wagon (default) and native transport
cstamas merged PR #158: URL: https://github.com/apache/maven-integration-testing/pull/158 -- 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-integration-testing] cstamas commented on pull request #158: [MNG-7470] mvn 3.9+ IT that uses wagon (default) and native transport
cstamas commented on PR #158: URL: https://github.com/apache/maven-integration-testing/pull/158#issuecomment-1124288722 https://github.com/apache/maven/pull/732 is merged, so am merging this one as well (ongoing branches not having merged PR will fail 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
[jira] [Assigned] (MDEP-804) Allow auto-ignore of all non-test scoped dependencies used only in test scope
[ https://issues.apache.org/jira/browse/MDEP-804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen reassigned MDEP-804: --- Assignee: Henning Schmiedehausen > Allow auto-ignore of all non-test scoped dependencies used only in test scope > - > > Key: MDEP-804 > URL: https://issues.apache.org/jira/browse/MDEP-804 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: analyze >Affects Versions: 3.3.0 >Reporter: Henning Schmiedehausen >Assignee: Henning Schmiedehausen >Priority: Major > Labels: pull-request-available > Fix For: wontfix-candidate > > > Pre-3.2.0, dependencies that were used only in test scope but not declared in > test scope (most likely declared in compile scope) were accepted by the > plugin and not flagged as a problem. > Starting with 3.2.0 (and the current 3.3.0), these are reported with > "Non-test scoped test only dependencies found". If the scope of the > dependencies can not be changed (there are many reasons for that in large > projects), the old behavior can be restored by adding each flagged dependency > to the "ignoredNonTestScopedDependencies" configuration option in the > respective project. > This is, especially in large projects, cumbersome and brittle. > There should be a boolean flag, "ignoreAllNonTestScoped" that, when set, > allows ignoring non-test scoped dependencies if they are used only in test > scope. This flag restores the pre-3.2.0 behavior. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (MNG-7475) [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in FileProfileActivator.setPathTranslator()
[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17535108#comment-17535108
]
Tamás Cservenák edited comment on MNG-7475 at 5/11/22 8:46 PM:
---
Same issue as in
https://issues.apache.org/jira/browse/MNG-7449?focusedCommentId=17518729=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17518729
You are (mis)using a component FileProfileActivator by manually constructing
it, while it is a managed component. Same fix applies as well, and you will
regain backward compatibility as well.
was (Author: cstamas):
Same issue as in
https://issues.apache.org/jira/browse/MNG-7449?focusedCommentId=17518729=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17518729
You are (mis)using a component FileProfileActivator by manually constructing,
while it is a managed component. Same fix applies as well, and you will regain
backward compatibility as well.
> [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in
> FileProfileActivator.setPathTranslator()
> -
>
> Key: MNG-7475
> URL: https://issues.apache.org/jira/browse/MNG-7475
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.8.5
> Environment: any & deterministically reproducible / proven by public
> API docs
>Reporter: Andreas Loew
>Priority: Major
>
> Maven 3.8.5 breaks [Arquillian
> ShrinkWrap|https://arquillian.org/modules/shrinkwrap-shrinkwrap] (and
> thereby, most if not all use of Red Hat/JBoss Arquillian) by changing the
> published public API of class
> org.apache.maven.model.profile.activation.FileProfileActivator:
> {code:java}
> [ERROR]
> com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest
> Time elapsed: 0.127 s <<< ERROR!
> java.lang.NoSuchMethodError:
> 'org.apache.maven.model.profile.activation.FileProfileActivator
> org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
> at
> org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
> at
> org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
> at
> org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
> at
> org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
> at
> org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
> at
> org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
> at
> org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:38)
> {code}
> It seems that method
> {code:java}
> public FileProfileActivator setPathTranslator( PathTranslator pathTranslator
> ) {code}
> as well as the class of its argument - has been refactored/renamed to
> {code:java}
> public FileProfileActivator setProfileActivationFilePathInterpolator(
> ProfileActivationFilePathInterpolator profileActivationFilePathInterpolator )
> {code}
> While the new name might be regarded as more stylish and/or even more
> appropriate, unfortunately, this results in an incompatible change of a
> publicly documented API:
> [https://maven.apache.org/ref/3.8.4/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> [https://maven.apache.org/ref/3.8.5/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> Therefore, please revert this change - it clearly breaks some valuable
> dependent software (which unfortunately is no longer maintained by RedHat)...
> Many thanks in advance! :)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-7475) [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in FileProfileActivator.setPathTranslator()
[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17535108#comment-17535108
]
Tamás Cservenák commented on MNG-7475:
--
Same issue as in
https://issues.apache.org/jira/browse/MNG-7449?focusedCommentId=17518729=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17518729
You are (mis)using a component FileProfileActivator by manually constructing,
while it is a managed component. Same fix applies as well, and you will regain
backward compatibility as well.
> [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in
> FileProfileActivator.setPathTranslator()
> -
>
> Key: MNG-7475
> URL: https://issues.apache.org/jira/browse/MNG-7475
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.8.5
> Environment: any & deterministically reproducible / proven by public
> API docs
>Reporter: Andreas Loew
>Priority: Major
>
> Maven 3.8.5 breaks [Arquillian
> ShrinkWrap|https://arquillian.org/modules/shrinkwrap-shrinkwrap] (and
> thereby, most if not all use of Red Hat/JBoss Arquillian) by changing the
> published public API of class
> org.apache.maven.model.profile.activation.FileProfileActivator:
> {code:java}
> [ERROR]
> com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest
> Time elapsed: 0.127 s <<< ERROR!
> java.lang.NoSuchMethodError:
> 'org.apache.maven.model.profile.activation.FileProfileActivator
> org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
> at
> org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
> at
> org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
> at
> org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
> at
> org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
> at
> org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
> at
> org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
> at
> org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:38)
> {code}
> It seems that method
> {code:java}
> public FileProfileActivator setPathTranslator( PathTranslator pathTranslator
> ) {code}
> as well as the class of its argument - has been refactored/renamed to
> {code:java}
> public FileProfileActivator setProfileActivationFilePathInterpolator(
> ProfileActivationFilePathInterpolator profileActivationFilePathInterpolator )
> {code}
> While the new name might be regarded as more stylish and/or even more
> appropriate, unfortunately, this results in an incompatible change of a
> publicly documented API:
> [https://maven.apache.org/ref/3.8.4/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> [https://maven.apache.org/ref/3.8.5/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> Therefore, please revert this change - it clearly breaks some valuable
> dependent software (which unfortunately is no longer maintained by RedHat)...
> Many thanks in advance! :)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-integration-testing] michael-o commented on pull request #158: [MNG-7470] mvn 3.9+ IT that uses wagon (default) and native transport
michael-o commented on PR #158: URL: https://github.com/apache/maven-integration-testing/pull/158#issuecomment-1124272468 Works for me now except for the JEtty log output which I don't understand -- 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] (MSITE-896) Is it possible to override the Project Reports menu order?
[ https://issues.apache.org/jira/browse/MSITE-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSITE-896: - Fix Version/s: waiting-for-feedback > Is it possible to override the Project Reports menu order? > -- > > Key: MSITE-896 > URL: https://issues.apache.org/jira/browse/MSITE-896 > Project: Maven Site Plugin > Issue Type: Wish >Reporter: Joshua >Priority: Major > Fix For: waiting-for-feedback > > Attachments: image-2022-04-27-15-50-48-346.png, > image-2022-04-27-15-51-39-355.png, image-2022-05-11-08-24-14-242.png > > > I have to inherit a parent pom per organization guidelines. > Inheriting that parent pom messes up the ordering of the report sets in the > generated project report menu. > Here is before the inheritance > !image-2022-04-27-15-50-48-346.png! > Here is after the inheritance > !image-2022-04-27-15-51-39-355.png! > Is there any way I can override/specify the order of the report sets in this > menu in either my pom or the site.xml? > I would like the after ordering to be the same as before ordering. > I can't change the parent pom which defines most of the report sets. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MSITE-896) Is it possible to override the Project Reports menu order?
[ https://issues.apache.org/jira/browse/MSITE-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17535106#comment-17535106 ] Michael Osipov commented on MSITE-896: -- Please also create two minimal projects: parent pom resembling org, actual project. > Is it possible to override the Project Reports menu order? > -- > > Key: MSITE-896 > URL: https://issues.apache.org/jira/browse/MSITE-896 > Project: Maven Site Plugin > Issue Type: Wish >Reporter: Joshua >Priority: Major > Attachments: image-2022-04-27-15-50-48-346.png, > image-2022-04-27-15-51-39-355.png, image-2022-05-11-08-24-14-242.png > > > I have to inherit a parent pom per organization guidelines. > Inheriting that parent pom messes up the ordering of the report sets in the > generated project report menu. > Here is before the inheritance > !image-2022-04-27-15-50-48-346.png! > Here is after the inheritance > !image-2022-04-27-15-51-39-355.png! > Is there any way I can override/specify the order of the report sets in this > menu in either my pom or the site.xml? > I would like the after ordering to be the same as before ordering. > I can't change the parent pom which defines most of the report sets. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MSITE-896) Is it possible to override the Project Reports menu order?
[ https://issues.apache.org/jira/browse/MSITE-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17535105#comment-17535105 ] Michael Osipov commented on MSITE-896: -- The bug is likely somewhere here: org.apache.maven.plugins.site.render.AbstractSiteRenderingMojo.locateDocuments(SiteRenderingContext, List, Locale) Please provide full verbose output for both runs. > Is it possible to override the Project Reports menu order? > -- > > Key: MSITE-896 > URL: https://issues.apache.org/jira/browse/MSITE-896 > Project: Maven Site Plugin > Issue Type: Wish >Reporter: Joshua >Priority: Major > Attachments: image-2022-04-27-15-50-48-346.png, > image-2022-04-27-15-51-39-355.png, image-2022-05-11-08-24-14-242.png > > > I have to inherit a parent pom per organization guidelines. > Inheriting that parent pom messes up the ordering of the report sets in the > generated project report menu. > Here is before the inheritance > !image-2022-04-27-15-50-48-346.png! > Here is after the inheritance > !image-2022-04-27-15-51-39-355.png! > Is there any way I can override/specify the order of the report sets in this > menu in either my pom or the site.xml? > I would like the after ordering to be the same as before ordering. > I can't change the parent pom which defines most of the report sets. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (MJAVADOC-652) Dependencies on the patch-module path
[ https://issues.apache.org/jira/browse/MJAVADOC-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil updated MJAVADOC-652: -- Affects Version/s: 3.4.0 3.3.2 3.3.1 3.3.0 > Dependencies on the patch-module path > - > > Key: MJAVADOC-652 > URL: https://issues.apache.org/jira/browse/MJAVADOC-652 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.4.0 >Reporter: Phil >Assignee: Robert Scholte >Priority: Major > Attachments: MJAVADOC-652-PATCHMODULE.zip, MJAVADOC-652.zip > > > When building with Java 11 (so >9) the Javadoc options argument is built > using the module-path and patch-module. Some of the dependencies I work with > are ending up in patch-module which generates an error on Javadoc creation - > class not found. > From what I can see from the code (3.2.0), the decision of which argument to > use is based on: > # If the dependency jar has a module-info.class, add to module-path > # If the dependency jar has a MANIFEST file with Automatic-Module-Name > defined, add to module-path. > # If neither of the above, add to patch-module. > The javax.servlet-API-3.1.0.jar, for example, has neither 1 nor 2, so gets > amended to the patch-module. This then prevents Javadoc generation because > Java is unable to link classes from the servlet API. If I put the servlet API > into the module-path manually it works fine. > From my understanding, patch-module is used to either override classes in a > module or augment contents of a module. In this case, it is its own 'module' > (I think) and should not be patched into my module. I do not see a reason to > put any of my dependencies into patch-module. > Is this a bug, or just an unfortunate consequence of having to deal with > non-modular dependencies when building under a Java version that supports > modules. For what it is worth, the project I work on does not use modules, > everything on -classpath works just fine. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MJAVADOC-652) Dependencies on the patch-module path
[ https://issues.apache.org/jira/browse/MJAVADOC-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17535103#comment-17535103 ] Phil commented on MJAVADOC-652: --- OK, so I uploaded a slightly changed version of the sample project. All it was missing to show the (in my opinion) incorrect use of the patch-module path was its own automatic module name, which I added to the Jar plugin in the POM. If you run: mvn -Ddebug=true clean package (You can inspect the Javadoc options in target/apidocs/options) This triggers the Javadoc plugin to treat the project as one that can support the module path. After which it determines the servlet-api should be placed on the `patch-module` path because it does not have an automatic module name (or module-info.class I think). Strangely this does not cause a Javadoc failure in this sample project, but it does in the much larger project I have where several external dependencies are being placed on the patch-module path. I do not believe the patch-module path should be used for external dependencies in this way? > Dependencies on the patch-module path > - > > Key: MJAVADOC-652 > URL: https://issues.apache.org/jira/browse/MJAVADOC-652 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.2.0 >Reporter: Phil >Assignee: Robert Scholte >Priority: Major > Attachments: MJAVADOC-652-PATCHMODULE.zip, MJAVADOC-652.zip > > > When building with Java 11 (so >9) the Javadoc options argument is built > using the module-path and patch-module. Some of the dependencies I work with > are ending up in patch-module which generates an error on Javadoc creation - > class not found. > From what I can see from the code (3.2.0), the decision of which argument to > use is based on: > # If the dependency jar has a module-info.class, add to module-path > # If the dependency jar has a MANIFEST file with Automatic-Module-Name > defined, add to module-path. > # If neither of the above, add to patch-module. > The javax.servlet-API-3.1.0.jar, for example, has neither 1 nor 2, so gets > amended to the patch-module. This then prevents Javadoc generation because > Java is unable to link classes from the servlet API. If I put the servlet API > into the module-path manually it works fine. > From my understanding, patch-module is used to either override classes in a > module or augment contents of a module. In this case, it is its own 'module' > (I think) and should not be patched into my module. I do not see a reason to > put any of my dependencies into patch-module. > Is this a bug, or just an unfortunate consequence of having to deal with > non-modular dependencies when building under a Java version that supports > modules. For what it is worth, the project I work on does not use modules, > everything on -classpath works just fine. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (MNG-7475) [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in FileProfileActivator.setPathTranslator()
[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7475:
Summary: [REGRESSION] ModelBuilder API Change breaks ShrinkWrap:
NoSuchMethodError in FileProfileActivator.setPathTranslator() (was:
ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in
FileProfileActivator.setPathTranslator())
> [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in
> FileProfileActivator.setPathTranslator()
> -
>
> Key: MNG-7475
> URL: https://issues.apache.org/jira/browse/MNG-7475
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.8.5
> Environment: any & deterministically reproducible / proven by public
> API docs
>Reporter: Andreas Loew
>Priority: Major
>
> Maven 3.8.5 breaks [Arquillian
> ShrinkWrap|https://arquillian.org/modules/shrinkwrap-shrinkwrap] (and
> thereby, most if not all use of Red Hat/JBoss Arquillian) by changing the
> published public API of class
> org.apache.maven.model.profile.activation.FileProfileActivator:
> {code:java}
> [ERROR]
> com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest
> Time elapsed: 0.127 s <<< ERROR!
> java.lang.NoSuchMethodError:
> 'org.apache.maven.model.profile.activation.FileProfileActivator
> org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
> at
> org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
> at
> org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
> at
> org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
> at
> org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
> at
> org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
> at
> org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
> at
> org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:38)
> {code}
> It seems that method
> {code:java}
> public FileProfileActivator setPathTranslator( PathTranslator pathTranslator
> ) {code}
> as well as the class of its argument - has been refactored/renamed to
> {code:java}
> public FileProfileActivator setProfileActivationFilePathInterpolator(
> ProfileActivationFilePathInterpolator profileActivationFilePathInterpolator )
> {code}
> While the new name might be regarded as more stylish and/or even more
> appropriate, unfortunately, this results in an incompatible change of a
> publicly documented API:
> [https://maven.apache.org/ref/3.8.4/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> [https://maven.apache.org/ref/3.8.5/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> Therefore, please revert this change - it clearly breaks some valuable
> dependent software (which unfortunately is no longer maintained by RedHat)...
> Many thanks in advance! :)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MJAVADOC-652) Dependencies on the patch-module path
[ https://issues.apache.org/jira/browse/MJAVADOC-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil updated MJAVADOC-652: -- Attachment: MJAVADOC-652-PATCHMODULE.zip > Dependencies on the patch-module path > - > > Key: MJAVADOC-652 > URL: https://issues.apache.org/jira/browse/MJAVADOC-652 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.2.0 >Reporter: Phil >Assignee: Robert Scholte >Priority: Major > Attachments: MJAVADOC-652-PATCHMODULE.zip, MJAVADOC-652.zip > > > When building with Java 11 (so >9) the Javadoc options argument is built > using the module-path and patch-module. Some of the dependencies I work with > are ending up in patch-module which generates an error on Javadoc creation - > class not found. > From what I can see from the code (3.2.0), the decision of which argument to > use is based on: > # If the dependency jar has a module-info.class, add to module-path > # If the dependency jar has a MANIFEST file with Automatic-Module-Name > defined, add to module-path. > # If neither of the above, add to patch-module. > The javax.servlet-API-3.1.0.jar, for example, has neither 1 nor 2, so gets > amended to the patch-module. This then prevents Javadoc generation because > Java is unable to link classes from the servlet API. If I put the servlet API > into the module-path manually it works fine. > From my understanding, patch-module is used to either override classes in a > module or augment contents of a module. In this case, it is its own 'module' > (I think) and should not be patched into my module. I do not see a reason to > put any of my dependencies into patch-module. > Is this a bug, or just an unfortunate consequence of having to deal with > non-modular dependencies when building under a Java version that supports > modules. For what it is worth, the project I work on does not use modules, > everything on -classpath works just fine. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MNG-7475) ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in FileProfileActivator.setPathTranslator()
[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17535096#comment-17535096
]
Michael Osipov commented on MNG-7475:
-
Code in question:
https://github.com/shrinkwrap/resolver/blob/f564882d785db86460f43cc7512650e3efae3380/maven/impl-maven/src/main/java/org/jboss/shrinkwrap/resolver/impl/maven/internal/SettingsXmlProfileSelector.java#L46-L51
Reverting this would also mean to break MNG-6802 which has been open for 3,5
years. We likely could make this happen in Maven 4, but then ShrinkWrap would
be broken anyway...
> ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in
> FileProfileActivator.setPathTranslator()
>
>
> Key: MNG-7475
> URL: https://issues.apache.org/jira/browse/MNG-7475
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.8.5
> Environment: any & deterministically reproducible / proven by public
> API docs
>Reporter: Andreas Loew
>Priority: Major
>
> Maven 3.8.5 breaks [Arquillian
> ShrinkWrap|https://arquillian.org/modules/shrinkwrap-shrinkwrap] (and
> thereby, most if not all use of Red Hat/JBoss Arquillian) by changing the
> published public API of class
> org.apache.maven.model.profile.activation.FileProfileActivator:
> {code:java}
> [ERROR]
> com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest
> Time elapsed: 0.127 s <<< ERROR!
> java.lang.NoSuchMethodError:
> 'org.apache.maven.model.profile.activation.FileProfileActivator
> org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
> at
> org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
> at
> org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
> at
> org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
> at
> org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
> at
> org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
> at
> org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
> at
> org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:38)
> {code}
> It seems that method
> {code:java}
> public FileProfileActivator setPathTranslator( PathTranslator pathTranslator
> ) {code}
> as well as the class of its argument - has been refactored/renamed to
> {code:java}
> public FileProfileActivator setProfileActivationFilePathInterpolator(
> ProfileActivationFilePathInterpolator profileActivationFilePathInterpolator )
> {code}
> While the new name might be regarded as more stylish and/or even more
> appropriate, unfortunately, this results in an incompatible change of a
> publicly documented API:
> [https://maven.apache.org/ref/3.8.4/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> [https://maven.apache.org/ref/3.8.5/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> Therefore, please revert this change - it clearly breaks some valuable
> dependent software (which unfortunately is no longer maintained by RedHat)...
> Many thanks in advance! :)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-7475) ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in FileProfileActivator.setPathTranslator()
[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17535097#comment-17535097
]
Michael Osipov commented on MNG-7475:
-
[~gnodet]
> ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in
> FileProfileActivator.setPathTranslator()
>
>
> Key: MNG-7475
> URL: https://issues.apache.org/jira/browse/MNG-7475
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.8.5
> Environment: any & deterministically reproducible / proven by public
> API docs
>Reporter: Andreas Loew
>Priority: Major
>
> Maven 3.8.5 breaks [Arquillian
> ShrinkWrap|https://arquillian.org/modules/shrinkwrap-shrinkwrap] (and
> thereby, most if not all use of Red Hat/JBoss Arquillian) by changing the
> published public API of class
> org.apache.maven.model.profile.activation.FileProfileActivator:
> {code:java}
> [ERROR]
> com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest
> Time elapsed: 0.127 s <<< ERROR!
> java.lang.NoSuchMethodError:
> 'org.apache.maven.model.profile.activation.FileProfileActivator
> org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
> at
> org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
> at
> org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
> at
> org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
> at
> org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
> at
> org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
> at
> org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
> at
> org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:38)
> {code}
> It seems that method
> {code:java}
> public FileProfileActivator setPathTranslator( PathTranslator pathTranslator
> ) {code}
> as well as the class of its argument - has been refactored/renamed to
> {code:java}
> public FileProfileActivator setProfileActivationFilePathInterpolator(
> ProfileActivationFilePathInterpolator profileActivationFilePathInterpolator )
> {code}
> While the new name might be regarded as more stylish and/or even more
> appropriate, unfortunately, this results in an incompatible change of a
> publicly documented API:
> [https://maven.apache.org/ref/3.8.4/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> [https://maven.apache.org/ref/3.8.5/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> Therefore, please revert this change - it clearly breaks some valuable
> dependent software (which unfortunately is no longer maintained by RedHat)...
> Many thanks in advance! :)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-7475) ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in FileProfileActivator.setPathTranslator()
[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17535095#comment-17535095
]
Michael Osipov commented on MNG-7475:
-
Interesting
This class one flaw, it should have been constructor injection. Setter
injection implies that it is optional which it is not. Moreover, this is a
managed component, you are supposed to receive a ready-to-go class, no manual
management.
[~cstamas]
> ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in
> FileProfileActivator.setPathTranslator()
>
>
> Key: MNG-7475
> URL: https://issues.apache.org/jira/browse/MNG-7475
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.8.5
> Environment: any & deterministically reproducible / proven by public
> API docs
>Reporter: Andreas Loew
>Priority: Major
>
> Maven 3.8.5 breaks [Arquillian
> ShrinkWrap|https://arquillian.org/modules/shrinkwrap-shrinkwrap] (and
> thereby, most if not all use of Red Hat/JBoss Arquillian) by changing the
> published public API of class
> org.apache.maven.model.profile.activation.FileProfileActivator:
> {code:java}
> [ERROR]
> com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest
> Time elapsed: 0.127 s <<< ERROR!
> java.lang.NoSuchMethodError:
> 'org.apache.maven.model.profile.activation.FileProfileActivator
> org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
> at
> org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
> at
> org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
> at
> org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
> at
> org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
> at
> org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
> at
> org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
> at
> org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:38)
> {code}
> It seems that method
> {code:java}
> public FileProfileActivator setPathTranslator( PathTranslator pathTranslator
> ) {code}
> as well as the class of its argument - has been refactored/renamed to
> {code:java}
> public FileProfileActivator setProfileActivationFilePathInterpolator(
> ProfileActivationFilePathInterpolator profileActivationFilePathInterpolator )
> {code}
> While the new name might be regarded as more stylish and/or even more
> appropriate, unfortunately, this results in an incompatible change of a
> publicly documented API:
> [https://maven.apache.org/ref/3.8.4/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> [https://maven.apache.org/ref/3.8.5/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> Therefore, please revert this change - it clearly breaks some valuable
> dependent software (which unfortunately is no longer maintained by RedHat)...
> Many thanks in advance! :)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MNG-7475) ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in FileProfileActivator.setPathTranslator()
[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Loew updated MNG-7475:
--
Description:
Maven 3.8.5 breaks [Arquillian
ShrinkWrap|https://arquillian.org/modules/shrinkwrap-shrinkwrap] (and thereby,
most if not all use of Red Hat/JBoss Arquillian) by changing the published
public API of class
org.apache.maven.model.profile.activation.FileProfileActivator:
{code:java}
[ERROR]
com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest Time
elapsed: 0.127 s <<< ERROR!
java.lang.NoSuchMethodError:
'org.apache.maven.model.profile.activation.FileProfileActivator
org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
at
org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
at
org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
at
org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
at
org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
at
org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
at
org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
at
org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:38)
{code}
It seems that method
{code:java}
public FileProfileActivator setPathTranslator( PathTranslator pathTranslator )
{code}
as well as the class of its argument - has been refactored/renamed to
{code:java}
public FileProfileActivator setProfileActivationFilePathInterpolator(
ProfileActivationFilePathInterpolator profileActivationFilePathInterpolator )
{code}
While the new name might be regarded as more stylish and/or even more
appropriate, unfortunately, this results in an incompatible change of a
publicly documented API:
[https://maven.apache.org/ref/3.8.4/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
[https://maven.apache.org/ref/3.8.5/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
Therefore, please revert this change - it clearly breaks some valuable
dependent software (which unfortunately is no longer maintained by RedHat)...
Many thanks in advance! :)
was:
Maven 3.8.5 breaks Arquillian ShrinkWrap (and thereby, most if not all use of
Red Hat/JBoss Arquillian) by changing the published public API of class
org.apache.maven.model.profile.activation.FileProfileActivator:
{code:java}
[ERROR]
com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest Time
elapsed: 0.127 s <<< ERROR!
java.lang.NoSuchMethodError:
'org.apache.maven.model.profile.activation.FileProfileActivator
org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
at
org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
at
org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
at
org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
at
org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
at
org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
at
[jira] [Updated] (MNG-7475) ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in FileProfileActivator.setPathTranslator()
[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Loew updated MNG-7475:
--
Description:
Maven 3.8.5 breaks Arquillian ShrinkWrap (and thereby, most if not all use of
Red Hat/JBoss Arquillian) by changing the published public API of class
org.apache.maven.model.profile.activation.FileProfileActivator:
{code:java}
[ERROR]
com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest Time
elapsed: 0.127 s <<< ERROR!
java.lang.NoSuchMethodError:
'org.apache.maven.model.profile.activation.FileProfileActivator
org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
at
org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
at
org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
at
org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
at
org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
at
org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
at
org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
at
org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:38)
{code}
It seems that method
{code:java}
public FileProfileActivator setPathTranslator( PathTranslator pathTranslator )
{code}
as well as the class of its argument - has been refactored/renamed to
{code:java}
public FileProfileActivator setProfileActivationFilePathInterpolator(
ProfileActivationFilePathInterpolator profileActivationFilePathInterpolator )
{code}
While the new name might be regarded as more stylish and/or even more
appropriate, unfortunately, this results in an incompatible change of a
publicly documented API:
[https://maven.apache.org/ref/3.8.4/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
[https://maven.apache.org/ref/3.8.5/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
Therefore, please revert this change - it clearly breaks some valuable
dependent software (which unfortunately is no longer maintained by RedHat)...
Many thanks in advance! :)
was:
Maven 3.8.5 breaks Arquillian ShrinkWrap (and thereby, most if not all use of
Arquillian) by changing public API of class
org.apache.maven.model.profile.activation.FileProfileActivator:
{code:java}
[ERROR]
com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest Time
elapsed: 0.127 s <<< ERROR!
java.lang.NoSuchMethodError:
'org.apache.maven.model.profile.activation.FileProfileActivator
org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
at
org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
at
org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
at
org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
at
org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
at
org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
at
[jira] [Updated] (MNG-7475) ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in FileProfileActivator.setPathTranslator()
[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Loew updated MNG-7475:
--
Description:
Maven 3.8.5 breaks Arquillian ShrinkWrap (and thereby, most if not all use of
Arquillian) by changing public API of class
org.apache.maven.model.profile.activation.FileProfileActivator:
{code:java}
[ERROR]
com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest Time
elapsed: 0.127 s <<< ERROR!
java.lang.NoSuchMethodError:
'org.apache.maven.model.profile.activation.FileProfileActivator
org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
at
org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
at
org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
at
org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
at
org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
at
org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
at
org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
at
org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:38)
{code}
It seems that method
{code:java}
public FileProfileActivator setPathTranslator( PathTranslator pathTranslator )
{code}
as well as the class of its argument - has been refactored/renamed to
{code:java}
public FileProfileActivator setProfileActivationFilePathInterpolator(
ProfileActivationFilePathInterpolator profileActivationFilePathInterpolator )
{code}
While the new name might be regarded as more stylish and/or even more
appropriate, unfortunately, this is an incompatible change of a publicly
documented API:
[https://maven.apache.org/ref/3.8.4/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
[https://maven.apache.org/ref/3.8.5/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
Therefore, please revert this change - it clearly breaks some valuable
dependent software (which unfortunately is no longer maintained by RedHat)...
Many thanks in advance! :)
was:
Maven 3.8.5 breaks Arquillian ShrinkWrap (and thereby, most if not all use of
Arquillian) by changing public API of class
org.apache.maven.model.profile.activation.FileProfileActivator:
{code:java}
[ERROR]
com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest Time
elapsed: 0.127 s <<< ERROR!
java.lang.NoSuchMethodError:
'org.apache.maven.model.profile.activation.FileProfileActivator
org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
at
org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
at
org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
at
org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
at
org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
at
org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
at
org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
at
[jira] [Created] (MNG-7475) ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in FileProfileActivator.setPathTranslator()
Andreas Loew created MNG-7475:
-
Summary: ModelBuilder API Change breaks ShrinkWrap:
NoSuchMethodError in FileProfileActivator.setPathTranslator()
Key: MNG-7475
URL: https://issues.apache.org/jira/browse/MNG-7475
Project: Maven
Issue Type: Bug
Components: General
Affects Versions: 3.8.5
Environment: any & deterministically reproducible / proven by public
API docs
Reporter: Andreas Loew
Maven 3.8.5 breaks Arquillian ShrinkWrap (and thereby, most if not all use of
Arquillian) by changing public API of class
org.apache.maven.model.profile.activation.FileProfileActivator:
{code:java}
[ERROR]
com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest Time
elapsed: 0.127 s <<< ERROR!
java.lang.NoSuchMethodError:
'org.apache.maven.model.profile.activation.FileProfileActivator
org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
at
org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
at
org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
at
org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
at
org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
at
org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
at
org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
at
org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:38)
{code}
It seems that method
{code:java}
public FileProfileActivator setPathTranslator( PathTranslator pathTranslator )
{code}
- as well as the class of its argument - has been refactored/renamed to
{code:java}
public FileProfileActivator setProfileActivationFilePathInterpolator(
ProfileActivationFilePathInterpolator profileActivationFilePathInterpolator )
{code}
While the new name might be regarded as more stylish and/or even more
appropriate, unfortunately, this is an incompatible change of a publicly
documented API:
https://maven.apache.org/ref/3.8.4/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html
https://maven.apache.org/ref/3.8.5/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html
Therefore, please revert this change - it clearly breaks some valuable
dependent software (which unfortunately is no longer maintained by RedHat)...
Many thanks in advance! :)
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (SUREFIRE-2076) BufferOverflowException when encoding message with null runMode
[
https://issues.apache.org/jira/browse/SUREFIRE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17535072#comment-17535072
]
Matthias J. Sax commented on SUREFIRE-2076:
---
[~tibordigana] [~zoltan.meze] – Did you see my last comment? Is there some
workaround or do we need to stick with `-M5` until `-M7` is released?
> BufferOverflowException when encoding message with null runMode
> ---
>
> Key: SUREFIRE-2076
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2076
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M6
>Reporter: Zoltan Meze
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M7
>
>
> Per
> [#issuecomment-1099231382|https://github.com/apache/maven-surefire/pull/518#issuecomment-1099231382],
>
> [#issuecomment-1099706229|https://github.com/apache/maven-surefire/pull/518#issuecomment-1099706229],
>
> [#pullrequestreview-951134938|https://github.com/apache/maven-surefire/pull/518#pullrequestreview-951134938]
> and
> [#issuecomment-1108371215|https://github.com/apache/maven-surefire/pull/518#issuecomment-1108371215]
> RunMode can be null causing BufferOverflowException when encoding message.
> Related to similar issue with null testIds:
> [SUREFIRE-2056|https://issues.apache.org/jira/browse/SUREFIRE-2056]
> [*AbstractStreamEncoder#encodeHeader*|https://github.com/apache/maven-surefire/blob/959c1e9cabb8d06c72f5ebd7eb6e56e9987eccf8/surefire-api/src/main/java/org/apache/maven/surefire/api/stream/AbstractStreamEncoder.java#L86]
> stores runMode in at least 3 bytes:
> * 1-byte length
> * 1-byte delimiter
> * length-bytes runMode
> * 1-byte delimiter
> In case of null runMode the encoded part becomes *0::* (exactly 3 bytes
> length)
> The issue is that
> [*AbstractStreamEncoder#estimateBufferLength*|https://github.com/apache/maven-surefire/blob/959c1e9cabb8d06c72f5ebd7eb6e56e9987eccf8/surefire-api/src/main/java/org/apache/maven/surefire/api/stream/AbstractStreamEncoder.java#L184]
> is not expecting/couting any bytes for runMode part in case of null runMode.
> This results in in BufferOverflowException becase the byte size of the
> message is underestimated.
> Exception thrown:
> {code:java}
> java.nio.BufferOverflowException
> at java.nio.Buffer.nextPutIndex(Buffer.java:547)
> at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:172)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeString(AbstractStreamEncoder.java:127)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeStringData(AbstractStreamEncoder.java:171)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encode(AbstractStreamEncoder.java:157)
> at
> org.apache.maven.surefire.booter.spi.EventChannelEncoder.encodeMessage(EventChannelEncoder.java:398)
> at
> org.apache.maven.surefire.booter.spi.EventChannelEncoder.setOutErr(EventChannelEncoder.java:188)
> at
> org.apache.maven.surefire.booter.spi.EventChannelEncoder.testOutput(EventChannelEncoder.java:183)
> at
> org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:113)
> at
> org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:44)
> at
> org.apache.maven.surefire.common.junit4.JUnit4RunListener.writeTestOutput(JUnit4RunListener.java:235)
> at
> org.apache.maven.surefire.api.report.ConsoleOutputCapture$ForwardingPrintStream.println(ConsoleOutputCapture.java:144)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-resolver] cstamas opened a new pull request, #177: Collapse collectors
cstamas opened a new pull request, #177: URL: https://github.com/apache/maven-resolver/pull/177 As DF (original) and BF (added in 1.8) started as copy-paste of each other, they share a LOT. This PR tries to minimize redundancy, still, not loosing clarity, so leaving inner Args class for each of 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-resolver] cstamas commented on pull request #176: Idea: collector listener
cstamas commented on PR #176: URL: https://github.com/apache/maven-resolver/pull/176#issuecomment-1124187787 All the code in "demo" segment originates from here https://github.com/grgrzybek/tracking-maven-extension/blob/main/src/main/java/org/ops4j/tools/maven/tracker/TrackingRepositoryListener.java#L168 -- 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-integration-testing] michael-o commented on pull request #158: [MNG-7470] mvn 3.9+ IT that uses wagon (default) and native transport
michael-o commented on PR #158: URL: https://github.com/apache/maven-integration-testing/pull/158#issuecomment-1124179020 Still testing... -- 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=17535054#comment-17535054
]
ASF GitHub Bot commented on MNG-7433:
-
gnodet commented on code in PR #730:
URL: https://github.com/apache/maven/pull/730#discussion_r870619812
##
maven-core/src/main/java/org/apache/maven/internal/MessageHelper.java:
##
@@ -0,0 +1,91 @@
+package org.apache.maven.internal;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.util.ArrayList;
+import java.util.List;
+
+/**
+ * Helper class to format warning messages to the console
+ */
+public class MessageHelper
+{
+
+private static final int DEFAULT_MAX_SIZE = 65;
Review Comment:
Yes, that's in [MessageUtils from
maven-shared-utils](https://github.com/apache/maven-shared-utils/blob/9f40037bfb04d54dd997a9ab837390045c9a4348/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java#L225-L236).
The reflow is already done dynamically, so that's not a problem.
However, we go through the logging system, so the caller will have to hard
code somehow the size needed for the `[WARN] ` prefix (or whatever can be
configured), as I don't think we can compute it easily.
I'll can give it a try at adding a parameter for the max length and have the
caller use it with the terminal width (and a maximum, as a one line message
might be hard to read... or not ? ).
> [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
>Assignee: Guillaume Nodet
>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.7#820007)
[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=17535053#comment-17535053
]
ASF GitHub Bot commented on MNG-7433:
-
michael-o commented on code in PR #730:
URL: https://github.com/apache/maven/pull/730#discussion_r870622821
##
maven-core/src/main/java/org/apache/maven/internal/MessageHelper.java:
##
@@ -0,0 +1,91 @@
+package org.apache.maven.internal;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.util.ArrayList;
+import java.util.List;
+
+/**
+ * Helper class to format warning messages to the console
+ */
+public class MessageHelper
+{
+
+private static final int DEFAULT_MAX_SIZE = 65;
Review Comment:
Alright, let's try. Otherwise we can leave it as is.
> [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
>Assignee: Guillaume Nodet
>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.7#820007)
[GitHub] [maven] gnodet commented on a diff in pull request #730: [MNG-7433] Warn if in parallel build aggregator Mojo found
gnodet commented on code in PR #730:
URL: https://github.com/apache/maven/pull/730#discussion_r870619812
##
maven-core/src/main/java/org/apache/maven/internal/MessageHelper.java:
##
@@ -0,0 +1,91 @@
+package org.apache.maven.internal;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.util.ArrayList;
+import java.util.List;
+
+/**
+ * Helper class to format warning messages to the console
+ */
+public class MessageHelper
+{
+
+private static final int DEFAULT_MAX_SIZE = 65;
Review Comment:
Yes, that's in [MessageUtils from
maven-shared-utils](https://github.com/apache/maven-shared-utils/blob/9f40037bfb04d54dd997a9ab837390045c9a4348/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java#L225-L236).
The reflow is already done dynamically, so that's not a problem.
However, we go through the logging system, so the caller will have to hard
code somehow the size needed for the `[WARN] ` prefix (or whatever can be
configured), as I don't think we can compute it easily.
I'll can give it a try at adding a parameter for the max length and have the
caller use it with the terminal width (and a maximum, as a one line message
might be hard to read... or not ? ).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] michael-o commented on a diff in pull request #730: [MNG-7433] Warn if in parallel build aggregator Mojo found
michael-o commented on code in PR #730:
URL: https://github.com/apache/maven/pull/730#discussion_r870622821
##
maven-core/src/main/java/org/apache/maven/internal/MessageHelper.java:
##
@@ -0,0 +1,91 @@
+package org.apache.maven.internal;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.util.ArrayList;
+import java.util.List;
+
+/**
+ * Helper class to format warning messages to the console
+ */
+public class MessageHelper
+{
+
+private static final int DEFAULT_MAX_SIZE = 65;
Review Comment:
Alright, let's try. Otherwise we can leave it as is.
--
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=17535052#comment-17535052
]
ASF GitHub Bot commented on MNG-7433:
-
gnodet commented on code in PR #730:
URL: https://github.com/apache/maven/pull/730#discussion_r870619812
##
maven-core/src/main/java/org/apache/maven/internal/MessageHelper.java:
##
@@ -0,0 +1,91 @@
+package org.apache.maven.internal;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.util.ArrayList;
+import java.util.List;
+
+/**
+ * Helper class to format warning messages to the console
+ */
+public class MessageHelper
+{
+
+private static final int DEFAULT_MAX_SIZE = 65;
Review Comment:
Yes, that's in
https://github.com/apache/maven-shared-utils/blob/9f40037bfb04d54dd997a9ab837390045c9a4348/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java#L225-L236
However, we go through the logging system, so this will have to guess the
size needed for the `[WARN] ` (or whatever can be configured) prefix, but I can
give it a try.
> [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
>Assignee: Guillaume Nodet
>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.7#820007)
[GitHub] [maven] gnodet commented on a diff in pull request #730: [MNG-7433] Warn if in parallel build aggregator Mojo found
gnodet commented on code in PR #730:
URL: https://github.com/apache/maven/pull/730#discussion_r870619812
##
maven-core/src/main/java/org/apache/maven/internal/MessageHelper.java:
##
@@ -0,0 +1,91 @@
+package org.apache.maven.internal;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.util.ArrayList;
+import java.util.List;
+
+/**
+ * Helper class to format warning messages to the console
+ */
+public class MessageHelper
+{
+
+private static final int DEFAULT_MAX_SIZE = 65;
Review Comment:
Yes, that's in
https://github.com/apache/maven-shared-utils/blob/9f40037bfb04d54dd997a9ab837390045c9a4348/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java#L225-L236
However, we go through the logging system, so this will have to guess the
size needed for the `[WARN] ` (or whatever can be configured) prefix, but I can
give it a try.
--
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 a diff in pull request #176: Idea: collector listener
michael-o commented on code in PR #176:
URL: https://github.com/apache/maven-resolver/pull/176#discussion_r870615618
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DependencyCollectorDelegate.java:
##
@@ -93,4 +100,28 @@ public DependencyCollector setVersionRangeResolver(
VersionRangeResolver version
return this;
}
+protected void dependencyCollected( RepositorySystemSession session,
+List
pathToCollectedNode,
+DependencyNode collectedNode )
+{
+// TODO: this is below "demo", but will be an extension point
Review Comment:
Don't use `String#format()` it is very expensive, your SLF4J placeholder.
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DependencyCollectorDelegate.java:
##
@@ -93,4 +100,28 @@ public DependencyCollector setVersionRangeResolver(
VersionRangeResolver version
return this;
}
+protected void dependencyCollected( RepositorySystemSession session,
+List
pathToCollectedNode,
+DependencyNode collectedNode )
+{
+// TODO: this is below "demo", but will be an extension point
+logger.info( String.format( "%s (context: %s)",
+collectedNode.getDependency(),
collectedNode.getRequestContext() ) );
+int distance = 0;
+ListIterator reversePathIterator = pathToCollectedNode
+.listIterator( pathToCollectedNode.size() );
+while ( reversePathIterator.hasPrevious() )
+{
+DependencyNode dn = reversePathIterator.previous();
+StringBuilder indent = new StringBuilder();
+for ( int i = 0; i < distance; i++ )
+{
+indent.append( " " );
+}
+distance++;
+indent.append( " -> " );
+logger.info( String.format( "%s%s (context: %s) @ %s", indent, dn,
dn.getRequestContext(),
Review Comment:
same 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
[jira] [Assigned] (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:all-tabpanel ] Michael Osipov reassigned MNG-7433: --- Assignee: Guillaume Nodet > [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 >Assignee: Guillaume Nodet >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.7#820007)
[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=17535045#comment-17535045
]
ASF GitHub Bot commented on MNG-7433:
-
michael-o commented on code in PR #730:
URL: https://github.com/apache/maven/pull/730#discussion_r870604293
##
maven-core/src/main/java/org/apache/maven/lifecycle/internal/MojoExecutor.java:
##
@@ -232,7 +237,17 @@ private static class ProjectLock implements AutoCloseable
boolean aggregator = mojoDescriptor.isAggregator();
acquiredAggregatorLock = aggregator ?
aggregatorLock.writeLock() : aggregatorLock.readLock();
acquiredProjectLock = getProjectLock( session );
-acquiredAggregatorLock.lock();
+if ( !acquiredAggregatorLock.tryLock() )
+{
+for ( String s : MessageHelper.formatWarning(
Review Comment:
An aggregator mojo is already being executed in this parallel build, those
kind of mojos require...
..until the aggregator mojo is done.
##
maven-core/src/main/java/org/apache/maven/internal/MessageHelper.java:
##
@@ -0,0 +1,91 @@
+package org.apache.maven.internal;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.util.ArrayList;
+import java.util.List;
+
+/**
+ * Helper class to format warning messages to the console
+ */
+public class MessageHelper
+{
+
+private static final int DEFAULT_MAX_SIZE = 65;
Review Comment:
Stupid question, didn't we introduce dynamic sizing with Jansi since we can
determine the terminal size?
Note: this would also require to auto-reflow the content...
> [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.7#820007)
[GitHub] [maven] michael-o commented on a diff in pull request #730: [MNG-7433] Warn if in parallel build aggregator Mojo found
michael-o commented on code in PR #730:
URL: https://github.com/apache/maven/pull/730#discussion_r870604293
##
maven-core/src/main/java/org/apache/maven/lifecycle/internal/MojoExecutor.java:
##
@@ -232,7 +237,17 @@ private static class ProjectLock implements AutoCloseable
boolean aggregator = mojoDescriptor.isAggregator();
acquiredAggregatorLock = aggregator ?
aggregatorLock.writeLock() : aggregatorLock.readLock();
acquiredProjectLock = getProjectLock( session );
-acquiredAggregatorLock.lock();
+if ( !acquiredAggregatorLock.tryLock() )
+{
+for ( String s : MessageHelper.formatWarning(
Review Comment:
An aggregator mojo is already being executed in this parallel build, those
kind of mojos require...
..until the aggregator mojo is done.
##
maven-core/src/main/java/org/apache/maven/internal/MessageHelper.java:
##
@@ -0,0 +1,91 @@
+package org.apache.maven.internal;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.util.ArrayList;
+import java.util.List;
+
+/**
+ * Helper class to format warning messages to the console
+ */
+public class MessageHelper
+{
+
+private static final int DEFAULT_MAX_SIZE = 65;
Review Comment:
Stupid question, didn't we introduce dynamic sizing with Jansi since we can
determine the terminal size?
Note: this would also require to auto-reflow the content...
--
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-integration-testing] cstamas commented on a diff in pull request #158: [MNG-7470] mvn 3.9+ IT that uses wagon (default) and native transport
cstamas commented on code in PR #158:
URL:
https://github.com/apache/maven-integration-testing/pull/158#discussion_r870565382
##
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng7470ResolverTransportTest.java:
##
@@ -0,0 +1,87 @@
+package org.apache.maven.it;
+
+import java.io.File;
+import java.util.HashMap;
+import java.util.List;
+
+import org.apache.maven.it.util.ResourceExtractor;
+
+/**
+ * This is a test set for https://issues.apache.org/jira/browse/MNG-7470;>MNG-7470:
+ * check that Maven two bundled transports works as expected.
+ */
+public class MavenITmng7470ResolverTransportTest
+extends AbstractMavenIntegrationTestCase
+{
+public MavenITmng7470ResolverTransportTest()
+{
+super( "[3.9.0,)" );
+}
+
+private void performTest( final String transport, final String logSnippet
) throws Exception
+{
+File testDir = ResourceExtractor.simpleExtractResources( getClass(),
"/mng-7470-resolver-transport" );
+
+HttpServer server = HttpServer.builder()
+.port( 0 )
+.source( new File( testDir, "repo" ) )
+.build();
+server.start();
+try
+{
+Verifier verifier = newVerifier( testDir.getAbsolutePath() );
+HashMap properties = new HashMap<>();
+properties.put( "@port@", Integer.toString( server.port() ) );
+verifier.filterFile( "settings-template.xml", "settings.xml",
"UTF-8", properties );
+
+verifier = newVerifier( new File( testDir, "project"
).getAbsolutePath() );
+verifier.setLogFileName( transport + "-transport.log" );
+verifier.deleteDirectory( "target" );
+verifier.deleteArtifacts(
"org.apache.maven.its.resolver-transport" );
+verifier.addCliOption( "-X" );
+verifier.addCliOption("-s" );
+verifier.addCliOption( new File( testDir, "settings.xml"
).getAbsolutePath() );
+verifier.addCliOption( "-Pmaven-core-it-repo" );
+verifier.addCliOption( "-Dmaven.resolver.transport=" + transport );
+// Maven will fail if project dependencies cannot be resolved.
+// As dependency exists ONLY in HTTP repo, it MUST be reached
using selected transport and
+// successfully resolved from it.
+verifier.executeGoal( "verify" );
+verifier.verifyErrorFreeLog();
+// verify maven console output contains "[DEBUG] Using transporter
XXXTransporter"
+verifyLogHasLine( verifier, logSnippet );
+verifier.resetStreams();
+}
+finally
+{
+server.stop();
+}
+}
+
+private void verifyLogHasLine( final Verifier verifier, final String
logSnippet )
Review Comment:
fixed
--
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-integration-testing] slawekjaranowski commented on a diff in pull request #158: [MNG-7470] mvn 3.9+ IT that uses wagon (default) and native transport
slawekjaranowski commented on code in PR #158:
URL:
https://github.com/apache/maven-integration-testing/pull/158#discussion_r870536089
##
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng7470ResolverTransportTest.java:
##
@@ -0,0 +1,87 @@
+package org.apache.maven.it;
+
+import java.io.File;
+import java.util.HashMap;
+import java.util.List;
+
+import org.apache.maven.it.util.ResourceExtractor;
+
+/**
+ * This is a test set for https://issues.apache.org/jira/browse/MNG-7470;>MNG-7470:
+ * check that Maven two bundled transports works as expected.
+ */
+public class MavenITmng7470ResolverTransportTest
+extends AbstractMavenIntegrationTestCase
+{
+public MavenITmng7470ResolverTransportTest()
+{
+super( "[3.9.0,)" );
+}
+
+private void performTest( final String transport, final String logSnippet
) throws Exception
+{
+File testDir = ResourceExtractor.simpleExtractResources( getClass(),
"/mng-7470-resolver-transport" );
+
+HttpServer server = HttpServer.builder()
+.port( 0 )
+.source( new File( testDir, "repo" ) )
+.build();
+server.start();
+try
+{
+Verifier verifier = newVerifier( testDir.getAbsolutePath() );
+HashMap properties = new HashMap<>();
+properties.put( "@port@", Integer.toString( server.port() ) );
+verifier.filterFile( "settings-template.xml", "settings.xml",
"UTF-8", properties );
+
+verifier = newVerifier( new File( testDir, "project"
).getAbsolutePath() );
+verifier.setLogFileName( transport + "-transport.log" );
+verifier.deleteDirectory( "target" );
+verifier.deleteArtifacts(
"org.apache.maven.its.resolver-transport" );
+verifier.addCliOption( "-X" );
+verifier.addCliOption("-s" );
+verifier.addCliOption( new File( testDir, "settings.xml"
).getAbsolutePath() );
+verifier.addCliOption( "-Pmaven-core-it-repo" );
+verifier.addCliOption( "-Dmaven.resolver.transport=" + transport );
+// Maven will fail if project dependencies cannot be resolved.
+// As dependency exists ONLY in HTTP repo, it MUST be reached
using selected transport and
+// successfully resolved from it.
+verifier.executeGoal( "verify" );
+verifier.verifyErrorFreeLog();
+// verify maven console output contains "[DEBUG] Using transporter
XXXTransporter"
+verifyLogHasLine( verifier, logSnippet );
+verifier.resetStreams();
+}
+finally
+{
+server.stop();
+}
+}
+
+private void verifyLogHasLine( final Verifier verifier, final String
logSnippet )
Review Comment:
There is `verifier.verifyTextInLog(...)`
--
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 opened a new pull request, #176: Idea: collector listener
cstamas opened a new pull request, #176: URL: https://github.com/apache/maven-resolver/pull/176 This basically does what this example did: https://github.com/grgrzybek/tracking-maven-extension To finish, it would be an "extension point": interface that if extension implements as component, would be picked up. BUT: am not quite in favor of this, as collector is HOT, and any time this listener would spend on work, would directly affect collection process. Am slowly leaning to simply define a callback for result graph (once collection is done), as then: * that would minimally affect collection, would not, would just add "postprocessing" cost, no in-processing cost that can quickly ass up * whole graph would be handed over, same as for caller along with session -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] eforx opened a new issue, #649: Maven goal is sometimes skipped
eforx opened a new issue, #649:
URL: https://github.com/apache/maven-mvnd/issues/649
In our CI pipeline, we call Maven Daemon in loop (single thread). Most of
the time it works, but about 1 out of 50 times mvnd skips the target goal.
Executed command: `mvnd
org.apache.maven.plugins:maven-dependency-plugin:3.2.0:get
-Dartifact=${mavenArtifactId} -ntp
-Dmaven.repo.local=${pathToLocalMavenRepository}`
Output log of single iteration looks like this
```
[INFO] Processing build on daemon 39c6fb35
[INFO] Scanning for projects...
[INFO] BuildTimeEventSpy is registered.
[INFO] Task segments :
[org.apache.maven.plugins:maven-dependency-plugin:3.2.0:get]
[INFO] Build maximum degree of concurrency is 1
[INFO] Total number of projects is 1
[INFO]
[INFO] --< org.apache.maven:standalone-pom
>---
[INFO] Building Maven Stub Project (No POM) 1
[INFO] [ pom
]-
[INFO]
[INFO] --- maven-dependency-plugin:3.2.0:get (default-cli) @ standalone-pom
---
[INFO] Resolving ${mavenArtifactId}:jar:1.2.3.4-SNAPSHOT with transitive
dependencies
[INFO] Segment walltime 0 s, segment projects service time 0 s,
effective/maximum degree of concurrency 0.62/1
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 0.186 s
[INFO] Finished at: 2022-05-11T16:02:15Z
[INFO]
```
while sometimes we got
```
[INFO] Processing build on daemon 39c6fb35
[INFO] Scanning for projects...
[INFO] BuildTimeEventSpy is registered.
[INFO] Task segments :
[org.apache.maven.plugins:maven-dependency-plugin:3.2.0:get]
[INFO] Build maximum degree of concurrency is 1
[INFO] Total number of projects is 1
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 0.008 s
[INFO] Finished at: 2022-05-11T16:02:15Z
[INFO]
```
--
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.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Created] (MNG-7474) SessionScoped beans should be singletons for a given session
Guillaume Nodet created MNG-7474: Summary: SessionScoped beans should be singletons for a given session Key: MNG-7474 URL: https://issues.apache.org/jira/browse/MNG-7474 Project: Maven Issue Type: Improvement Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 3.9.0-candidate Investigate an solution different from MNG-7347. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven] cstamas commented on a diff in pull request #735: Trasnport: use config properties instead user properties.
cstamas commented on code in PR #735: URL: https://github.com/apache/maven/pull/735#discussion_r870431077 ## maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java: ## @@ -261,8 +261,7 @@ else if ( request.isUpdateSnapshots() ) } session.setAuthenticationSelector( authSelector ); -String transport = request.getUserProperties() -.getProperty( MAVEN_RESOLVER_TRANSPORT_KEY, MAVEN_RESOLVER_TRANSPORT_WAGON ); Review Comment: IMHO this is correct change: we do want to allow setting transport in various ways, allowing the change to be "persistent". What we have on master works ONLY if you use `-Dmaven.resolver.transport=xx` on CLI and nothing else. This also allows CLI override (ie. you have it set in MAVEN_OPTS but you use `-Dxxx` on command line) -- 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 a diff in pull request #735: Trasnport: use config properties instead user properties.
cstamas commented on code in PR #735: URL: https://github.com/apache/maven/pull/735#discussion_r870431077 ## maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java: ## @@ -261,8 +261,7 @@ else if ( request.isUpdateSnapshots() ) } session.setAuthenticationSelector( authSelector ); -String transport = request.getUserProperties() -.getProperty( MAVEN_RESOLVER_TRANSPORT_KEY, MAVEN_RESOLVER_TRANSPORT_WAGON ); Review Comment: IMHO this is correct change: we do want to allow setting transport in various ways, allowing the change to be "persistent". What we have on master works ONLY if you use `-Dmaven.resolver.transport=xx` on CLI and nothing else. -- 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-7471) Resolver 1.8.0 introduces binary breakage in plugin using Resolver
[
https://issues.apache.org/jira/browse/MNG-7471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17534943#comment-17534943
]
Hudson commented on MNG-7471:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » maven-3.9.x #29
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.9.x/29/
> Resolver 1.8.0 introduces binary breakage in plugin using Resolver
> --
>
> Key: MNG-7471
> URL: https://issues.apache.org/jira/browse/MNG-7471
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.9.0-candidate
>Reporter: Tamás Cservenák
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> With Maven 3.9.0-SNAPSHOT (post MNG-7453 done) there is a binary breakage
> introduced for plugins using Resolver, as proven by new IT MNG-7470.
> Problem is following:
> Maven Core exports following packages:
> * resolver-api
> * resolver-spi
> * resolver-impl
> While plugin will have added its "own" versions of these below to plugin
> realm:
> * resolver-util
> * resolver-connector-basic
> This means, that a plugin will be forced to use api/spi/imp from core
> (1.8.0), but they will keep using their own util and connector-basic.
> Resolver 1.8.0 introduces API changes that affects all of impl,
> connector-basic and spi, basically their own copy of connector-basic will
> fail. The interface change from resolver-spi will prevent class from
> resolver-connector-basic to be instantiated.
> Error that is thrown during execution of plugin using Resolver:
> {{Caused by: org.apache.maven.plugin.PluginContainerException: An API
> incompatibility was encountered while executing
> io.quarkus:quarkus-maven-plugin:2.3.1.Final:build:
> java.lang.NoSuchMethodError: 'java.util.List
> org.eclipse.aether.spi.connector.layout.RepositoryLayout.getChecksums(org.eclipse.aether.artifact.Artifact,
> boolean, java.net.URI)'}}
> Important note: the error is triggered only when remote download happens, so
> even IT will pass OK with 3.9.0-SNAPSHOT IF local repository is
> pre-populated, hence, no remote download happens!
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven] slawekjaranowski commented on a diff in pull request #735: Trasnport: use config properties instead user properties.
slawekjaranowski commented on code in PR #735: URL: https://github.com/apache/maven/pull/735#discussion_r870423542 ## maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java: ## @@ -261,8 +261,7 @@ else if ( request.isUpdateSnapshots() ) } session.setAuthenticationSelector( authSelector ); -String transport = request.getUserProperties() -.getProperty( MAVEN_RESOLVER_TRANSPORT_KEY, MAVEN_RESOLVER_TRANSPORT_WAGON ); Review Comment: `request.*Properties` are populated in https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java -- 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] slawekjaranowski commented on a diff in pull request #735: Trasnport: use config properties instead user properties.
slawekjaranowski commented on code in PR #735: URL: https://github.com/apache/maven/pull/735#discussion_r870423542 ## maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java: ## @@ -261,8 +261,7 @@ else if ( request.isUpdateSnapshots() ) } session.setAuthenticationSelector( authSelector ); -String transport = request.getUserProperties() -.getProperty( MAVEN_RESOLVER_TRANSPORT_KEY, MAVEN_RESOLVER_TRANSPORT_WAGON ); Review Comment: `request.*Properties` is populated in https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java -- 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-7471) Resolver 1.8.0 introduces binary breakage in plugin using Resolver
[
https://issues.apache.org/jira/browse/MNG-7471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17534940#comment-17534940
]
Hudson commented on MNG-7471:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » master #43
See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/43/
> Resolver 1.8.0 introduces binary breakage in plugin using Resolver
> --
>
> Key: MNG-7471
> URL: https://issues.apache.org/jira/browse/MNG-7471
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.9.0-candidate
>Reporter: Tamás Cservenák
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> With Maven 3.9.0-SNAPSHOT (post MNG-7453 done) there is a binary breakage
> introduced for plugins using Resolver, as proven by new IT MNG-7470.
> Problem is following:
> Maven Core exports following packages:
> * resolver-api
> * resolver-spi
> * resolver-impl
> While plugin will have added its "own" versions of these below to plugin
> realm:
> * resolver-util
> * resolver-connector-basic
> This means, that a plugin will be forced to use api/spi/imp from core
> (1.8.0), but they will keep using their own util and connector-basic.
> Resolver 1.8.0 introduces API changes that affects all of impl,
> connector-basic and spi, basically their own copy of connector-basic will
> fail. The interface change from resolver-spi will prevent class from
> resolver-connector-basic to be instantiated.
> Error that is thrown during execution of plugin using Resolver:
> {{Caused by: org.apache.maven.plugin.PluginContainerException: An API
> incompatibility was encountered while executing
> io.quarkus:quarkus-maven-plugin:2.3.1.Final:build:
> java.lang.NoSuchMethodError: 'java.util.List
> org.eclipse.aether.spi.connector.layout.RepositoryLayout.getChecksums(org.eclipse.aether.artifact.Artifact,
> boolean, java.net.URI)'}}
> Important note: the error is triggered only when remote download happens, so
> even IT will pass OK with 3.9.0-SNAPSHOT IF local repository is
> pre-populated, hence, no remote download happens!
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven] michael-o commented on a diff in pull request #735: Trasnport: use config properties instead user properties.
michael-o commented on code in PR #735: URL: https://github.com/apache/maven/pull/735#discussion_r870405282 ## maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java: ## @@ -261,8 +261,7 @@ else if ( request.isUpdateSnapshots() ) } session.setAuthenticationSelector( authSelector ); -String transport = request.getUserProperties() -.getProperty( MAVEN_RESOLVER_TRANSPORT_KEY, MAVEN_RESOLVER_TRANSPORT_WAGON ); Review Comment: Look into Maven CLI, that is the source for it. Commons CLI provides it and it is passed down the line. -- 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 a diff in pull request #735: Trasnport: use config properties instead user properties.
cstamas commented on code in PR #735: URL: https://github.com/apache/maven/pull/735#discussion_r870393670 ## maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java: ## @@ -261,8 +261,7 @@ else if ( request.isUpdateSnapshots() ) } session.setAuthenticationSelector( authSelector ); -String transport = request.getUserProperties() -.getProperty( MAVEN_RESOLVER_TRANSPORT_KEY, MAVEN_RESOLVER_TRANSPORT_WAGON ); Review Comment: yup, this is "config" properties (merged plus added things). I think I understand from where "request.systemProperties" are sourced, but from where are "request.userProperties" sourced? -- 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 a diff in pull request #735: Trasnport: use config properties instead user properties.
michael-o commented on code in PR #735: URL: https://github.com/apache/maven/pull/735#discussion_r870388634 ## maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java: ## @@ -261,8 +261,7 @@ else if ( request.isUpdateSnapshots() ) } session.setAuthenticationSelector( authSelector ); -String transport = request.getUserProperties() -.getProperty( MAVEN_RESOLVER_TRANSPORT_KEY, MAVEN_RESOLVER_TRANSPORT_WAGON ); Review Comment: So this is a merged, final version of the properties and the actual source is irrelevant? -- 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 opened a new pull request, #735: Trasnport: use config properties instead user properties.
cstamas opened a new pull request, #735: URL: https://github.com/apache/maven/pull/735 This setting should be possible to be set via MAVEN_OPTS (system wide) or in .mvn/maven.config etc, Currently it is possible only via `-Dxxx` AFTER mvn -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MNG-7455) [REGRESSION] IllegalStateException in SessionScope during guice injection in multithreaded build
[
https://issues.apache.org/jira/browse/MNG-7455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MNG-7455.
Fix Version/s: 3.8.6
Assignee: Guillaume Nodet
Resolution: Fixed
> [REGRESSION] IllegalStateException in SessionScope during guice injection in
> multithreaded build
>
>
> Key: MNG-7455
> URL: https://issues.apache.org/jira/browse/MNG-7455
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.5
>Reporter: Emond Papegaaij
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 3.8.6
>
> Attachments: pom.xml.effective
>
>
> Since Maven 3.8.5 we are seeing intermittent failures with the stacktrace
> below. With 3.8.4 we did not have this issue. Looking at the changelog I
> suspect this regression is caused by MNG-7347.
> {code:java}
> 09:36:53 [mvn-builder-keyhub-manual] [INFO] ---
> asciidoctor-maven-plugin:2.2.2:process-asciidoc (output-html-nl) @
> keyhub-manual ---
> 09:36:53 [mvn-builder-keyhub-manual] [WARNING] Error injecting:
> org.asciidoctor.maven.AsciidoctorMojo
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) Error in custom provider, java.lang.IllegalStateException
> at
> org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.session.scope.internal.SessionScopeModule)
> while locating org.apache.maven.execution.MavenSession
> for field at org.asciidoctor.maven.AsciidoctorMojo.session(Unknown Source)
> while locating org.asciidoctor.maven.AsciidoctorMojo
> 1 error
> at
> com.google.inject.internal.InternalProvisionException.toProvisionException
> (InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get (InjectorImpl.java:1053)
> at com.google.inject.internal.InjectorImpl.getInstance
> (InjectorImpl.java:1086)
> at org.eclipse.sisu.space.AbstractDeferredClass.get
> (AbstractDeferredClass.java:48)
> at com.google.inject.internal.ProviderInternalFactory.provision
> (ProviderInternalFactory.java:85)
> at
> com.google.inject.internal.InternalFactoryToInitializableAdapter.provision
> (InternalFactoryToInitializableAdapter.java:57)
> at com.google.inject.internal.ProviderInternalFactory$1.call
> (ProviderInternalFactory.java:66)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision
> (ProvisionListenerStackCallback.java:112)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision
> (ProvisionListenerStackCallback.java:127)
> at com.google.inject.internal.ProvisionListenerStackCallback.provision
> (ProvisionListenerStackCallback.java:66)
> at com.google.inject.internal.ProviderInternalFactory.circularGet
> (ProviderInternalFactory.java:61)
> at com.google.inject.internal.InternalFactoryToInitializableAdapter.get
> (InternalFactoryToInitializableAdapter.java:47)
> at com.google.inject.internal.InjectorImpl$1.get (InjectorImpl.java:1050)
> at org.eclipse.sisu.inject.Guice4$1.get (Guice4.java:162)
> at org.eclipse.sisu.inject.LazyBeanEntry.getValue (LazyBeanEntry.java:81)
> at org.eclipse.sisu.plexus.LazyPlexusBean.getValue
> (LazyPlexusBean.java:51)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup
> (DefaultPlexusContainer.java:263)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup
> (DefaultPlexusContainer.java:255)
> at
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo
> (DefaultMavenPluginManager.java:520)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:124)
> 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.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:210)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:195)
> at java.util.concurrent.FutureTask.run (FutureTask.java:264)
> at java.util.concurrent.Executors$RunnableAdapter.call
> (Executors.java:539)
> at java.util.concurrent.FutureTask.run
[GitHub] [maven-integration-testing] cstamas commented on pull request #158: [MNG-7470] mvn 3.9+ IT that uses wagon (default) and native transport
cstamas commented on PR #158: URL: https://github.com/apache/maven-integration-testing/pull/158#issuecomment-1123846265 Fix merged, so the IT can be as well -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MSKINS-187) Wrong left margin for externalLink decoration in sideBar
[
https://issues.apache.org/jira/browse/MSKINS-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17534924#comment-17534924
]
Michael Osipov commented on MSKINS-187:
---
Look at the margin of "Project Reports", it is -6px. I would align both after
an investigation. Will work on a PR tomorrow.
> Wrong left margin for externalLink decoration in sideBar
>
>
> Key: MSKINS-187
> URL: https://issues.apache.org/jira/browse/MSKINS-187
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Affects Versions: fluido-1.10.0
>Reporter: Konrad Windszus
>Assignee: Michael Osipov
>Priority: Major
> Fix For: fluido-1.11.0
>
> Attachments: Screenshot 2022-05-11 at 15.31.17.png,
> image-2022-05-11-15-47-18-117.png
>
>
> External links get some decoration via CSS class "externalLink". The left
> margin is not correct though for external links appearing in the side bar.
> !Screenshot 2022-05-11 at 15.31.17.png!
> That is due to the left-margin of -15px set for {{.nav-list>li>a}}.
> A similar issue has been reported in MSKINS-173.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MNG-7471) Resolver 1.8.0 introduces binary breakage in plugin using Resolver
[
https://issues.apache.org/jira/browse/MNG-7471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MNG-7471:
-
Fix Version/s: 4.0.0
> Resolver 1.8.0 introduces binary breakage in plugin using Resolver
> --
>
> Key: MNG-7471
> URL: https://issues.apache.org/jira/browse/MNG-7471
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.9.0-candidate
>Reporter: Tamás Cservenák
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> With Maven 3.9.0-SNAPSHOT (post MNG-7453 done) there is a binary breakage
> introduced for plugins using Resolver, as proven by new IT MNG-7470.
> Problem is following:
> Maven Core exports following packages:
> * resolver-api
> * resolver-spi
> * resolver-impl
> While plugin will have added its "own" versions of these below to plugin
> realm:
> * resolver-util
> * resolver-connector-basic
> This means, that a plugin will be forced to use api/spi/imp from core
> (1.8.0), but they will keep using their own util and connector-basic.
> Resolver 1.8.0 introduces API changes that affects all of impl,
> connector-basic and spi, basically their own copy of connector-basic will
> fail. The interface change from resolver-spi will prevent class from
> resolver-connector-basic to be instantiated.
> Error that is thrown during execution of plugin using Resolver:
> {{Caused by: org.apache.maven.plugin.PluginContainerException: An API
> incompatibility was encountered while executing
> io.quarkus:quarkus-maven-plugin:2.3.1.Final:build:
> java.lang.NoSuchMethodError: 'java.util.List
> org.eclipse.aether.spi.connector.layout.RepositoryLayout.getChecksums(org.eclipse.aether.artifact.Artifact,
> boolean, java.net.URI)'}}
> Important note: the error is triggered only when remote download happens, so
> even IT will pass OK with 3.9.0-SNAPSHOT IF local repository is
> pre-populated, hence, no remote download happens!
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (MNG-7471) Resolver 1.8.0 introduces binary breakage in plugin using Resolver
[
https://issues.apache.org/jira/browse/MNG-7471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák closed MNG-7471.
> Resolver 1.8.0 introduces binary breakage in plugin using Resolver
> --
>
> Key: MNG-7471
> URL: https://issues.apache.org/jira/browse/MNG-7471
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.9.0-candidate
>Reporter: Tamás Cservenák
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1
>
>
> With Maven 3.9.0-SNAPSHOT (post MNG-7453 done) there is a binary breakage
> introduced for plugins using Resolver, as proven by new IT MNG-7470.
> Problem is following:
> Maven Core exports following packages:
> * resolver-api
> * resolver-spi
> * resolver-impl
> While plugin will have added its "own" versions of these below to plugin
> realm:
> * resolver-util
> * resolver-connector-basic
> This means, that a plugin will be forced to use api/spi/imp from core
> (1.8.0), but they will keep using their own util and connector-basic.
> Resolver 1.8.0 introduces API changes that affects all of impl,
> connector-basic and spi, basically their own copy of connector-basic will
> fail. The interface change from resolver-spi will prevent class from
> resolver-connector-basic to be instantiated.
> Error that is thrown during execution of plugin using Resolver:
> {{Caused by: org.apache.maven.plugin.PluginContainerException: An API
> incompatibility was encountered while executing
> io.quarkus:quarkus-maven-plugin:2.3.1.Final:build:
> java.lang.NoSuchMethodError: 'java.util.List
> org.eclipse.aether.spi.connector.layout.RepositoryLayout.getChecksums(org.eclipse.aether.artifact.Artifact,
> boolean, java.net.URI)'}}
> Important note: the error is triggered only when remote download happens, so
> even IT will pass OK with 3.9.0-SNAPSHOT IF local repository is
> pre-populated, hence, no remote download happens!
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MNG-7471) Resolver 1.8.0 introduces binary breakage in plugin using Resolver
[
https://issues.apache.org/jira/browse/MNG-7471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MNG-7471:
-
Fix Version/s: 3.9.0
4.0.0-alpha-1
> Resolver 1.8.0 introduces binary breakage in plugin using Resolver
> --
>
> Key: MNG-7471
> URL: https://issues.apache.org/jira/browse/MNG-7471
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.9.0-candidate
>Reporter: Tamás Cservenák
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1
>
>
> With Maven 3.9.0-SNAPSHOT (post MNG-7453 done) there is a binary breakage
> introduced for plugins using Resolver, as proven by new IT MNG-7470.
> Problem is following:
> Maven Core exports following packages:
> * resolver-api
> * resolver-spi
> * resolver-impl
> While plugin will have added its "own" versions of these below to plugin
> realm:
> * resolver-util
> * resolver-connector-basic
> This means, that a plugin will be forced to use api/spi/imp from core
> (1.8.0), but they will keep using their own util and connector-basic.
> Resolver 1.8.0 introduces API changes that affects all of impl,
> connector-basic and spi, basically their own copy of connector-basic will
> fail. The interface change from resolver-spi will prevent class from
> resolver-connector-basic to be instantiated.
> Error that is thrown during execution of plugin using Resolver:
> {{Caused by: org.apache.maven.plugin.PluginContainerException: An API
> incompatibility was encountered while executing
> io.quarkus:quarkus-maven-plugin:2.3.1.Final:build:
> java.lang.NoSuchMethodError: 'java.util.List
> org.eclipse.aether.spi.connector.layout.RepositoryLayout.getChecksums(org.eclipse.aether.artifact.Artifact,
> boolean, java.net.URI)'}}
> Important note: the error is triggered only when remote download happens, so
> even IT will pass OK with 3.9.0-SNAPSHOT IF local repository is
> pre-populated, hence, no remote download happens!
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (MNG-7471) Resolver 1.8.0 introduces binary breakage in plugin using Resolver
[
https://issues.apache.org/jira/browse/MNG-7471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák resolved MNG-7471.
--
Resolution: Fixed
> Resolver 1.8.0 introduces binary breakage in plugin using Resolver
> --
>
> Key: MNG-7471
> URL: https://issues.apache.org/jira/browse/MNG-7471
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.9.0-candidate
>Reporter: Tamás Cservenák
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1
>
>
> With Maven 3.9.0-SNAPSHOT (post MNG-7453 done) there is a binary breakage
> introduced for plugins using Resolver, as proven by new IT MNG-7470.
> Problem is following:
> Maven Core exports following packages:
> * resolver-api
> * resolver-spi
> * resolver-impl
> While plugin will have added its "own" versions of these below to plugin
> realm:
> * resolver-util
> * resolver-connector-basic
> This means, that a plugin will be forced to use api/spi/imp from core
> (1.8.0), but they will keep using their own util and connector-basic.
> Resolver 1.8.0 introduces API changes that affects all of impl,
> connector-basic and spi, basically their own copy of connector-basic will
> fail. The interface change from resolver-spi will prevent class from
> resolver-connector-basic to be instantiated.
> Error that is thrown during execution of plugin using Resolver:
> {{Caused by: org.apache.maven.plugin.PluginContainerException: An API
> incompatibility was encountered while executing
> io.quarkus:quarkus-maven-plugin:2.3.1.Final:build:
> java.lang.NoSuchMethodError: 'java.util.List
> org.eclipse.aether.spi.connector.layout.RepositoryLayout.getChecksums(org.eclipse.aether.artifact.Artifact,
> boolean, java.net.URI)'}}
> Important note: the error is triggered only when remote download happens, so
> even IT will pass OK with 3.9.0-SNAPSHOT IF local repository is
> pre-populated, hence, no remote download happens!
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-7471) Resolver 1.8.0 introduces binary breakage in plugin using Resolver
[
https://issues.apache.org/jira/browse/MNG-7471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17534922#comment-17534922
]
Tamás Cservenák commented on MNG-7471:
--
Merged as
maven-3.9.x 4de39476ff690774ece57637e91653d2ef234fd3
master a83ed86c4850c3fc09e5623eb00869ab3e39c959
> Resolver 1.8.0 introduces binary breakage in plugin using Resolver
> --
>
> Key: MNG-7471
> URL: https://issues.apache.org/jira/browse/MNG-7471
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.9.0-candidate
>Reporter: Tamás Cservenák
>Priority: Major
>
> With Maven 3.9.0-SNAPSHOT (post MNG-7453 done) there is a binary breakage
> introduced for plugins using Resolver, as proven by new IT MNG-7470.
> Problem is following:
> Maven Core exports following packages:
> * resolver-api
> * resolver-spi
> * resolver-impl
> While plugin will have added its "own" versions of these below to plugin
> realm:
> * resolver-util
> * resolver-connector-basic
> This means, that a plugin will be forced to use api/spi/imp from core
> (1.8.0), but they will keep using their own util and connector-basic.
> Resolver 1.8.0 introduces API changes that affects all of impl,
> connector-basic and spi, basically their own copy of connector-basic will
> fail. The interface change from resolver-spi will prevent class from
> resolver-connector-basic to be instantiated.
> Error that is thrown during execution of plugin using Resolver:
> {{Caused by: org.apache.maven.plugin.PluginContainerException: An API
> incompatibility was encountered while executing
> io.quarkus:quarkus-maven-plugin:2.3.1.Final:build:
> java.lang.NoSuchMethodError: 'java.util.List
> org.eclipse.aether.spi.connector.layout.RepositoryLayout.getChecksums(org.eclipse.aether.artifact.Artifact,
> boolean, java.net.URI)'}}
> Important note: the error is triggered only when remote download happens, so
> even IT will pass OK with 3.9.0-SNAPSHOT IF local repository is
> pre-populated, hence, no remote download happens!
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-7471) Resolver 1.8.0 introduces binary breakage in plugin using Resolver
[
https://issues.apache.org/jira/browse/MNG-7471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17534921#comment-17534921
]
ASF GitHub Bot commented on MNG-7471:
-
cstamas closed pull request #732: [MNG-7471] 3.9.x Make Resolver util and
connector-basic provided
URL: https://github.com/apache/maven/pull/732
> Resolver 1.8.0 introduces binary breakage in plugin using Resolver
> --
>
> Key: MNG-7471
> URL: https://issues.apache.org/jira/browse/MNG-7471
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.9.0-candidate
>Reporter: Tamás Cservenák
>Priority: Major
>
> With Maven 3.9.0-SNAPSHOT (post MNG-7453 done) there is a binary breakage
> introduced for plugins using Resolver, as proven by new IT MNG-7470.
> Problem is following:
> Maven Core exports following packages:
> * resolver-api
> * resolver-spi
> * resolver-impl
> While plugin will have added its "own" versions of these below to plugin
> realm:
> * resolver-util
> * resolver-connector-basic
> This means, that a plugin will be forced to use api/spi/imp from core
> (1.8.0), but they will keep using their own util and connector-basic.
> Resolver 1.8.0 introduces API changes that affects all of impl,
> connector-basic and spi, basically their own copy of connector-basic will
> fail. The interface change from resolver-spi will prevent class from
> resolver-connector-basic to be instantiated.
> Error that is thrown during execution of plugin using Resolver:
> {{Caused by: org.apache.maven.plugin.PluginContainerException: An API
> incompatibility was encountered while executing
> io.quarkus:quarkus-maven-plugin:2.3.1.Final:build:
> java.lang.NoSuchMethodError: 'java.util.List
> org.eclipse.aether.spi.connector.layout.RepositoryLayout.getChecksums(org.eclipse.aether.artifact.Artifact,
> boolean, java.net.URI)'}}
> Important note: the error is triggered only when remote download happens, so
> even IT will pass OK with 3.9.0-SNAPSHOT IF local repository is
> pre-populated, hence, no remote download happens!
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-7471) Resolver 1.8.0 introduces binary breakage in plugin using Resolver
[
https://issues.apache.org/jira/browse/MNG-7471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17534920#comment-17534920
]
ASF GitHub Bot commented on MNG-7471:
-
cstamas commented on PR #732:
URL: https://github.com/apache/maven/pull/732#issuecomment-1123820300
Merged manually:
maven-3.9.x 4de39476ff690774ece57637e91653d2ef234fd3
master a83ed86c4850c3fc09e5623eb00869ab3e39c959
> Resolver 1.8.0 introduces binary breakage in plugin using Resolver
> --
>
> Key: MNG-7471
> URL: https://issues.apache.org/jira/browse/MNG-7471
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.9.0-candidate
>Reporter: Tamás Cservenák
>Priority: Major
>
> With Maven 3.9.0-SNAPSHOT (post MNG-7453 done) there is a binary breakage
> introduced for plugins using Resolver, as proven by new IT MNG-7470.
> Problem is following:
> Maven Core exports following packages:
> * resolver-api
> * resolver-spi
> * resolver-impl
> While plugin will have added its "own" versions of these below to plugin
> realm:
> * resolver-util
> * resolver-connector-basic
> This means, that a plugin will be forced to use api/spi/imp from core
> (1.8.0), but they will keep using their own util and connector-basic.
> Resolver 1.8.0 introduces API changes that affects all of impl,
> connector-basic and spi, basically their own copy of connector-basic will
> fail. The interface change from resolver-spi will prevent class from
> resolver-connector-basic to be instantiated.
> Error that is thrown during execution of plugin using Resolver:
> {{Caused by: org.apache.maven.plugin.PluginContainerException: An API
> incompatibility was encountered while executing
> io.quarkus:quarkus-maven-plugin:2.3.1.Final:build:
> java.lang.NoSuchMethodError: 'java.util.List
> org.eclipse.aether.spi.connector.layout.RepositoryLayout.getChecksums(org.eclipse.aether.artifact.Artifact,
> boolean, java.net.URI)'}}
> Important note: the error is triggered only when remote download happens, so
> even IT will pass OK with 3.9.0-SNAPSHOT IF local repository is
> pre-populated, hence, no remote download happens!
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven] cstamas closed pull request #732: [MNG-7471] 3.9.x Make Resolver util and connector-basic provided
cstamas closed pull request #732: [MNG-7471] 3.9.x Make Resolver util and connector-basic provided URL: https://github.com/apache/maven/pull/732 -- 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 #732: [MNG-7471] 3.9.x Make Resolver util and connector-basic provided
cstamas commented on PR #732: URL: https://github.com/apache/maven/pull/732#issuecomment-1123820300 Merged manually: maven-3.9.x 4de39476ff690774ece57637e91653d2ef234fd3 master a83ed86c4850c3fc09e5623eb00869ab3e39c959 -- 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] (MSKINS-187) Wrong left margin for externalLink decoration in sideBar
[
https://issues.apache.org/jira/browse/MSKINS-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17534914#comment-17534914
]
Konrad Windszus commented on MSKINS-187:
[~michael-o] Yes, that looks much nicer. I haven't really thought about a
reasonable margin right, but the current 0 margin is just ugly. Your proposal
sounds fine to me.
> Wrong left margin for externalLink decoration in sideBar
>
>
> Key: MSKINS-187
> URL: https://issues.apache.org/jira/browse/MSKINS-187
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Affects Versions: fluido-1.10.0
>Reporter: Konrad Windszus
>Assignee: Michael Osipov
>Priority: Major
> Fix For: fluido-1.11.0
>
> Attachments: Screenshot 2022-05-11 at 15.31.17.png,
> image-2022-05-11-15-47-18-117.png
>
>
> External links get some decoration via CSS class "externalLink". The left
> margin is not correct though for external links appearing in the side bar.
> !Screenshot 2022-05-11 at 15.31.17.png!
> That is due to the left-margin of -15px set for {{.nav-list>li>a}}.
> A similar issue has been reported in MSKINS-173.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (MSKINS-187) Wrong left margin for externalLink decoration in sideBar
[
https://issues.apache.org/jira/browse/MSKINS-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MSKINS-187:
-
Assignee: Michael Osipov
> Wrong left margin for externalLink decoration in sideBar
>
>
> Key: MSKINS-187
> URL: https://issues.apache.org/jira/browse/MSKINS-187
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Affects Versions: fluido-1.10.0
>Reporter: Konrad Windszus
>Assignee: Michael Osipov
>Priority: Major
> Attachments: Screenshot 2022-05-11 at 15.31.17.png,
> image-2022-05-11-15-47-18-117.png
>
>
> External links get some decoration via CSS class "externalLink". The left
> margin is not correct though for external links appearing in the side bar.
> !Screenshot 2022-05-11 at 15.31.17.png!
> That is due to the left-margin of -15px set for {{.nav-list>li>a}}.
> A similar issue has been reported in MSKINS-173.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MSKINS-187) Wrong left margin for externalLink decoration in sideBar
[
https://issues.apache.org/jira/browse/MSKINS-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSKINS-187:
--
Fix Version/s: fluido-1.11.0
> Wrong left margin for externalLink decoration in sideBar
>
>
> Key: MSKINS-187
> URL: https://issues.apache.org/jira/browse/MSKINS-187
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Affects Versions: fluido-1.10.0
>Reporter: Konrad Windszus
>Assignee: Michael Osipov
>Priority: Major
> Fix For: fluido-1.11.0
>
> Attachments: Screenshot 2022-05-11 at 15.31.17.png,
> image-2022-05-11-15-47-18-117.png
>
>
> External links get some decoration via CSS class "externalLink". The left
> margin is not correct though for external links appearing in the side bar.
> !Screenshot 2022-05-11 at 15.31.17.png!
> That is due to the left-margin of -15px set for {{.nav-list>li>a}}.
> A similar issue has been reported in MSKINS-173.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MSKINS-187) Wrong left margin for externalLink decoration in sideBar
[
https://issues.apache.org/jira/browse/MSKINS-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSKINS-187:
--
Attachment: image-2022-05-11-15-47-18-117.png
> Wrong left margin for externalLink decoration in sideBar
>
>
> Key: MSKINS-187
> URL: https://issues.apache.org/jira/browse/MSKINS-187
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Affects Versions: fluido-1.10.0
>Reporter: Konrad Windszus
>Priority: Major
> Attachments: Screenshot 2022-05-11 at 15.31.17.png,
> image-2022-05-11-15-47-18-117.png
>
>
> External links get some decoration via CSS class "externalLink". The left
> margin is not correct though for external links appearing in the side bar.
> !Screenshot 2022-05-11 at 15.31.17.png!
> That is due to the left-margin of -15px set for {{.nav-list>li>a}}.
> A similar issue has been reported in MSKINS-173.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MSKINS-187) Wrong left margin for externalLink decoration in sideBar
[
https://issues.apache.org/jira/browse/MSKINS-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17534912#comment-17534912
]
Michael Osipov commented on MSKINS-187:
---
Is this what you expect to see
Alignment with the menu chevron?
> Wrong left margin for externalLink decoration in sideBar
>
>
> Key: MSKINS-187
> URL: https://issues.apache.org/jira/browse/MSKINS-187
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Affects Versions: fluido-1.10.0
>Reporter: Konrad Windszus
>Priority: Major
> Attachments: Screenshot 2022-05-11 at 15.31.17.png,
> image-2022-05-11-15-47-18-117.png
>
>
> External links get some decoration via CSS class "externalLink". The left
> margin is not correct though for external links appearing in the side bar.
> !Screenshot 2022-05-11 at 15.31.17.png!
> That is due to the left-margin of -15px set for {{.nav-list>li>a}}.
> A similar issue has been reported in MSKINS-173.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-integration-testing] cstamas commented on a diff in pull request #158: [MNG-7470] mvn 3.9+ IT that uses wagon (default) and native transport
cstamas commented on code in PR #158:
URL:
https://github.com/apache/maven-integration-testing/pull/158#discussion_r870318471
##
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng7470ResolverTransportTest.java:
##
@@ -0,0 +1,87 @@
+package org.apache.maven.it;
+
+import java.io.File;
+import java.util.HashMap;
+import java.util.List;
+
+import org.apache.maven.it.util.ResourceExtractor;
+
+/**
+ * This is a test set for https://issues.apache.org/jira/browse/MNG-7470;>MNG-7470:
+ * check that Maven two bundled transports works as expected.
+ */
+public class MavenITmng7470ResolverTransportTest
+extends AbstractMavenIntegrationTestCase
+{
+public MavenITmng7470ResolverTransportTest()
+{
+super( "[3.9.0,)" );
+}
+
+private void performTest( final String transport, final String logSnippet
) throws Exception
+{
+File testDir = ResourceExtractor.simpleExtractResources( getClass(),
"/mng-7470-resolver-transport" );
+
+HttpServer server = HttpServer.builder()
+.port( 0 )
+.source( new File( testDir, "repo" ) )
+.build();
+server.start();
+try
+{
+Verifier verifier = newVerifier( testDir.getAbsolutePath() );
+HashMap properties = new HashMap<>();
+properties.put( "@port@", Integer.toString( server.port() ) );
+verifier.filterFile( "settings-template.xml", "settings.xml",
"UTF-8", properties );
+
+verifier = newVerifier( new File( testDir, "project"
).getAbsolutePath() );
+verifier.setLogFileName( transport + "-transport.log" );
+verifier.deleteDirectory( "target" );
+verifier.deleteArtifacts(
"org.apache.maven.its.resolver-transport" );
+verifier.addCliOption( "-X" );
+verifier.addCliOption("-s" );
+verifier.addCliOption( new File( testDir, "settings.xml"
).getAbsolutePath() );
+verifier.addCliOption( "-Pmaven-core-it-repo" );
+verifier.addCliOption( "-Dmaven.resolver.transport=" + transport );
+// Maven will fail if project dependencies cannot be resolved.
+// As dependency exists ONLY in HTTP repo, it MUST be reached
using selected transport and
+// successfully resolved from it.
+verifier.executeGoal( "verify" );
+verifier.verifyErrorFreeLog();
+// verify maven console output contains "[DEBUG] Using transporter
XXXTransporter"
+verifyLogHasLine( verifier, logSnippet );
+verifier.resetStreams();
+}
+finally
+{
+server.stop();
+}
+}
+
+private void verifyLogHasLine( final Verifier verifier, final String
logSnippet )
Review Comment:
Agreed
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Created] (MSKINS-187) Wrong left margin for externalLink decoration in sideBar
Konrad Windszus created MSKINS-187:
--
Summary: Wrong left margin for externalLink decoration in sideBar
Key: MSKINS-187
URL: https://issues.apache.org/jira/browse/MSKINS-187
Project: Maven Skins
Issue Type: Bug
Components: Fluido Skin
Affects Versions: fluido-1.10.0
Reporter: Konrad Windszus
Attachments: Screenshot 2022-05-11 at 15.31.17.png
External links get some decoration via CSS class "externalLink". The left
margin is not correct though for external links appearing in the side bar.
!Screenshot 2022-05-11 at 15.31.17.png!
That is due to the left-margin of -15px set for {{.nav-list>li>a}}.
A similar issue has been reported in MSKINS-173.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-integration-testing] michael-o commented on a diff in pull request #158: [MNG-7470] mvn 3.9+ IT that uses wagon (default) and native transport
michael-o commented on code in PR #158:
URL:
https://github.com/apache/maven-integration-testing/pull/158#discussion_r870300031
##
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng7470ResolverTransportTest.java:
##
@@ -0,0 +1,87 @@
+package org.apache.maven.it;
+
+import java.io.File;
+import java.util.HashMap;
+import java.util.List;
+
+import org.apache.maven.it.util.ResourceExtractor;
+
+/**
+ * This is a test set for https://issues.apache.org/jira/browse/MNG-7470;>MNG-7470:
+ * check that Maven two bundled transports works as expected.
+ */
+public class MavenITmng7470ResolverTransportTest
+extends AbstractMavenIntegrationTestCase
+{
+public MavenITmng7470ResolverTransportTest()
+{
+super( "[3.9.0,)" );
+}
+
+private void performTest( final String transport, final String logSnippet
) throws Exception
+{
+File testDir = ResourceExtractor.simpleExtractResources( getClass(),
"/mng-7470-resolver-transport" );
+
+HttpServer server = HttpServer.builder()
+.port( 0 )
+.source( new File( testDir, "repo" ) )
+.build();
+server.start();
+try
+{
+Verifier verifier = newVerifier( testDir.getAbsolutePath() );
+HashMap properties = new HashMap<>();
+properties.put( "@port@", Integer.toString( server.port() ) );
+verifier.filterFile( "settings-template.xml", "settings.xml",
"UTF-8", properties );
+
+verifier = newVerifier( new File( testDir, "project"
).getAbsolutePath() );
+verifier.setLogFileName( transport + "-transport.log" );
+verifier.deleteDirectory( "target" );
+verifier.deleteArtifacts(
"org.apache.maven.its.resolver-transport" );
+verifier.addCliOption( "-X" );
+verifier.addCliOption("-s" );
Review Comment:
space
##
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng7470ResolverTransportTest.java:
##
@@ -0,0 +1,87 @@
+package org.apache.maven.it;
+
+import java.io.File;
+import java.util.HashMap;
+import java.util.List;
+
+import org.apache.maven.it.util.ResourceExtractor;
+
+/**
+ * This is a test set for https://issues.apache.org/jira/browse/MNG-7470;>MNG-7470:
+ * check that Maven two bundled transports works as expected.
+ */
+public class MavenITmng7470ResolverTransportTest
+extends AbstractMavenIntegrationTestCase
+{
+public MavenITmng7470ResolverTransportTest()
+{
+super( "[3.9.0,)" );
+}
+
+private void performTest( final String transport, final String logSnippet
) throws Exception
+{
+File testDir = ResourceExtractor.simpleExtractResources( getClass(),
"/mng-7470-resolver-transport" );
+
+HttpServer server = HttpServer.builder()
+.port( 0 )
+.source( new File( testDir, "repo" ) )
+.build();
+server.start();
+try
+{
+Verifier verifier = newVerifier( testDir.getAbsolutePath() );
+HashMap properties = new HashMap<>();
+properties.put( "@port@", Integer.toString( server.port() ) );
+verifier.filterFile( "settings-template.xml", "settings.xml",
"UTF-8", properties );
+
+verifier = newVerifier( new File( testDir, "project"
).getAbsolutePath() );
+verifier.setLogFileName( transport + "-transport.log" );
+verifier.deleteDirectory( "target" );
+verifier.deleteArtifacts(
"org.apache.maven.its.resolver-transport" );
+verifier.addCliOption( "-X" );
+verifier.addCliOption("-s" );
+verifier.addCliOption( new File( testDir, "settings.xml"
).getAbsolutePath() );
+verifier.addCliOption( "-Pmaven-core-it-repo" );
+verifier.addCliOption( "-Dmaven.resolver.transport=" + transport );
+// Maven will fail if project dependencies cannot be resolved.
+// As dependency exists ONLY in HTTP repo, it MUST be reached
using selected transport and
+// successfully resolved from it.
+verifier.executeGoal( "verify" );
+verifier.verifyErrorFreeLog();
+// verify maven console output contains "[DEBUG] Using transporter
XXXTransporter"
+verifyLogHasLine( verifier, logSnippet );
+verifier.resetStreams();
+}
+finally
+{
+server.stop();
+}
+}
+
+private void verifyLogHasLine( final Verifier verifier, final String
logSnippet )
Review Comment:
I bet I have seen this in other ITs already. I guess `Verifier` needs this
bundled. Out of scope for this PR.
--
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
[jira] [Commented] (MJAVADOC-713) Skipping Javadoc reportset leaves empty Javadoc link in site
[ https://issues.apache.org/jira/browse/MJAVADOC-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17534903#comment-17534903 ] Joshua commented on MJAVADOC-713: - [~michael-o] Any updates here? It says waiting for feedback and I have already provided a sample project. > Skipping Javadoc reportset leaves empty Javadoc link in site > > > Key: MJAVADOC-713 > URL: https://issues.apache.org/jira/browse/MJAVADOC-713 > Project: Maven Javadoc Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Joshua >Priority: Major > Fix For: waiting-for-feedback > > Attachments: image-2022-04-15-17-47-49-771.png, sampleproject.zip > > > I am trying to skip a reportset that is inherited from a parent pom > This is what the report plugin looks like in the parent pom > > org.apache.maven.plugins > maven-javadoc-plugin > > > javadoc-no-fork > > javadoc-no-fork > > > > test-javadoc-no-fork > > test-javadoc-no-fork > > > package > > > > > I don't want the test-javadoc-no-fork report in my project > > If I do this in my pom > > org.apache.maven.plugins > maven-javadoc-plugin > > > test-javadoc-no-fork > > true > > > > > > It will skip the Javadoc generation but still adds a link to site and when > you click on the link you get a 404 since the test Javadoc wasn't inherited. > !image-2022-04-15-17-47-49-771.png! > I logged this as a defect because I would think skip would prevent the > Javadoc generation and NOT add a link to the site for a report set that > wasn't generated. > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (MSITE-896) Is it possible to override the Project Reports menu order?
[ https://issues.apache.org/jira/browse/MSITE-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua updated MSITE-896: - Attachment: image-2022-05-11-08-24-14-242.png > Is it possible to override the Project Reports menu order? > -- > > Key: MSITE-896 > URL: https://issues.apache.org/jira/browse/MSITE-896 > Project: Maven Site Plugin > Issue Type: Wish >Reporter: Joshua >Priority: Major > Attachments: image-2022-04-27-15-50-48-346.png, > image-2022-04-27-15-51-39-355.png, image-2022-05-11-08-24-14-242.png > > > I have to inherit a parent pom per organization guidelines. > Inheriting that parent pom messes up the ordering of the report sets in the > generated project report menu. > Here is before the inheritance > !image-2022-04-27-15-50-48-346.png! > Here is after the inheritance > !image-2022-04-27-15-51-39-355.png! > Is there any way I can override/specify the order of the report sets in this > menu in either my pom or the site.xml? > I would like the after ordering to be the same as before ordering. > I can't change the parent pom which defines most of the report sets. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MSITE-896) Is it possible to override the Project Reports menu order?
[ https://issues.apache.org/jira/browse/MSITE-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17534902#comment-17534902 ] Joshua commented on MSITE-896: -- [~michael-o] I did try not using the in my site.xml and instead I just put each report in the site.xml The only problem with that is that there are certain times when spotbugs, pmd, and cpd reports aren't generated due to their being no issues. !image-2022-05-11-08-24-14-242.png! I am not sure how to detect in the site.xml whether the report it there or not before adding the item to the menu. > Is it possible to override the Project Reports menu order? > -- > > Key: MSITE-896 > URL: https://issues.apache.org/jira/browse/MSITE-896 > Project: Maven Site Plugin > Issue Type: Wish >Reporter: Joshua >Priority: Major > Attachments: image-2022-04-27-15-50-48-346.png, > image-2022-04-27-15-51-39-355.png, image-2022-05-11-08-24-14-242.png > > > I have to inherit a parent pom per organization guidelines. > Inheriting that parent pom messes up the ordering of the report sets in the > generated project report menu. > Here is before the inheritance > !image-2022-04-27-15-50-48-346.png! > Here is after the inheritance > !image-2022-04-27-15-51-39-355.png! > Is there any way I can override/specify the order of the report sets in this > menu in either my pom or the site.xml? > I would like the after ordering to be the same as before ordering. > I can't change the parent pom which defines most of the report sets. -- This message was sent by Atlassian Jira (v8.20.7#820007)
