[jira] [Created] (SUREFIRE-2073) Surefire should fork before class scan
Piotr Karwasz created SUREFIRE-2073:
---
Summary: Surefire should fork before class scan
Key: SUREFIRE-2073
URL: https://issues.apache.org/jira/browse/SUREFIRE-2073
Project: Maven Surefire
Issue Type: Bug
Components: JUnit 5.x support
Affects Versions: 3.0.0-M6
Reporter: Piotr Karwasz
On projects using toolchains submodules can be compiled with a different Java
version than the main project. This can result in an
{{UnsupportedClassVersionError}} if the class scan is performed by the main
Maven JVM:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (test) on project
log4j-api-java9: Execution test of goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed:
java.lang.UnsupportedClassVersionError:
org/apache/logging/log4j/util/java9/ProcessIdUtilTest has been compiled by a
more recent version of the Java Runtime (class file version 53.0), this version
of the Java Runtime only recognizes class file versions up to 52.0 -> [Help
1]{noformat}
Therefore Surefire should probably fork a new instance to scan for test classes
whenever {{forkCount}} is not zero.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2067) Improve site configuration
[
https://issues.apache.org/jira/browse/SUREFIRE-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522068#comment-17522068
]
Olivier Lamy commented on SUREFIRE-2067:
So impressed by [~hboutemy] memory!!!
https://github.com/apache/maven-surefire/commit/1479079a2082738a832d0b2bc4dc11d57e574a04
the old good time when we didn't have white or grey hair 🤣
> Improve site configuration
> --
>
> Key: SUREFIRE-2067
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2067
> Project: Maven Surefire
> Issue Type: Improvement
> Components: documentation
>Reporter: Slawomir Jaranowski
>Priority: Major
>
> Configuration like: {{bannerLeft}}, {{bannerRight}}, skin version should be
> taken from parent.
> Currently we have old Maven logo on documentation site.
> We have also enabled {{topBar}} which is not enabled on other Maven project,
> so it is some of inconsistent.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] dependabot[bot] opened a new pull request, #520: Bump jacocoVersion from 0.8.7 to 0.8.8
dependabot[bot] opened a new pull request, #520: URL: https://github.com/apache/maven-surefire/pull/520 Bumps `jacocoVersion` from 0.8.7 to 0.8.8. Updates `org.jacoco.agent` from 0.8.7 to 0.8.8 Release notes Sourced from https://github.com/jacoco/jacoco/releases";>org.jacoco.agent's releases. 0.8.8 New Features JaCoCo now officially supports Java 17 and 18 (GitHub https://github-redirect.dependabot.com/jacoco/jacoco/issues/1282";>#1282, https://github-redirect.dependabot.com/jacoco/jacoco/issues/1198";>#1198). Experimental support for Java 19 class files (GitHub https://github-redirect.dependabot.com/jacoco/jacoco/issues/1264";>#1264). Part of bytecode generated by the Java compilers for assert statement is filtered out during generation of report (GitHub https://github-redirect.dependabot.com/jacoco/jacoco/issues/1196";>#1196). Branch added by the Kotlin compiler version 1.6.0 and above for "unsafe" cast operator is filtered out during generation of report (GitHub https://github-redirect.dependabot.com/jacoco/jacoco/issues/1266";>#1266). Improved support for multiple JaCoCo runtimes in the same VM (GitHub https://github-redirect.dependabot.com/jacoco/jacoco/issues/1057";>#1057). Fixed bugs Fixed NullPointerException during filtering (GitHub https://github-redirect.dependabot.com/jacoco/jacoco/issues/1189";>#1189). Fix range for debug symbols of method parameters (GitHub https://github-redirect.dependabot.com/jacoco/jacoco/issues/1246";>#1246). Non-functional Changes JaCoCo now depends on ASM 9.2 (GitHub https://github-redirect.dependabot.com/jacoco/jacoco/issues/1206";>#1206). Messages of exceptions occurring during analysis or instrumentation now include JaCoCo version (GitHub https://github-redirect.dependabot.com/jacoco/jacoco/issues/1217";>#1217). Commits https://github.com/jacoco/jacoco/commit/5dcf34ad180c125ee3214437b0ca4f9b7b6258fc";>5dcf34a Prepare release 0.8.8 https://github.com/jacoco/jacoco/commit/aa16a7c25cfc119ba3486bb114d3d54dc1bcca6c";>aa16a7c Improve support for multiple JaCoCo runtimes in the same VM (https://github-redirect.dependabot.com/jacoco/jacoco/issues/1057";>#1057) https://github.com/jacoco/jacoco/commit/7e516b1eaba146f0b5c05cfc3c3ac1a2a0735cb8";>7e516b1 Update documentation: JDK versions 17 and 18 are officially supported (https://github-redirect.dependabot.com/jacoco/jacoco/issues/1282";>#1282) https://github.com/jacoco/jacoco/commit/c54fa8a521022ac9af9a8c2f0533b2652d5d205a";>c54fa8a Include JaCoCo version in instrumentation/analysis exception messages (https://github-redirect.dependabot.com/jacoco/jacoco/issues/1217";>#1217) https://github.com/jacoco/jacoco/commit/046ba52e9fd1288cf121fd1013c9019d71946954";>046ba52 Happy New Year 2022! https://github.com/jacoco/jacoco/commit/2036acc5d2e88fed74b9a70728af1bebedb34055";>2036acc Update KotlinUnsafeCastOperatorFilter for Kotlin 1.6 (https://github-redirect.dependabot.com/jacoco/jacoco/issues/1266";>#1266) https://github.com/jacoco/jacoco/commit/ac756b60c029d0acf5e1202c9966b2c5a79b6b8c";>ac756b6 Add experimental support for Java 19 class files (https://github-redirect.dependabot.com/jacoco/jacoco/issues/1264";>#1264) https://github.com/jacoco/jacoco/commit/a0cf1e6c0ce9bbfeda705201278689a01b3d274b";>a0cf1e6 Upgrade gmavenplus-plugin to 1.13.0 (https://github-redirect.dependabot.com/jacoco/jacoco/issues/1253";>#1253) https://github.com/jacoco/jacoco/commit/024de66740f7308ce98b6ce895a4ae1d049d282d";>024de66 Fix build for JDK 18 >= EA b21 (https://github-redirect.dependabot.com/jacoco/jacoco/issues/1249";>#1249) https://github.com/jacoco/jacoco/commit/70d5b98d8c438126e9e95f186017ef972b031ef8";>70d5b98 Fix range for debug symbols of method parameters (https://github-redirect.dependabot.com/jacoco/jacoco/issues/1246";>#1246) Additional commits viewable in https://github.com/jacoco/jacoco/compare/v0.8.7...v0.8.8";>compare view Updates `jacoco-maven-plugin` from 0.8.7 to 0.8.8 Release notes Sourced from https://github.com/jacoco/jacoco/releases";>jacoco-maven-plugin's releases. 0.8.8 New Features JaCoCo now officially supports Java 17 and 18 (GitHub https://github-redirect.dependabot.com/jacoco/jacoco/issues/1282";>#1282, https://github-redirect.dependabot.com/jacoco/jacoco/issues/1198";>#1198). Experimental support for Java 19 class files (GitHub https://github-redirect.dependabot.com/jacoco/jacoco/issues/1264";>#1264). Part of bytecode generated by the Java compilers for assert statement is filtered out during generation of report (GitHub https://github-redirect.dependabot.com/jacoco/jacoco/issues/1196";>#1196). Branch added by the Kotlin compiler version 1.6.0 and above for "unsafe" cast operator is filtered out during generation of report (GitHub https://github-redirect.dependabot.com/jacoco/jacoco/issues/1266";>#1266). Im
[jira] [Updated] (MNG-7461) Maven to exclude list/wildcard of groupId's or artifactId's from particular repository
[ https://issues.apache.org/jira/browse/MNG-7461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kapil Singal updated MNG-7461: -- Description: Let's say an artifact with GAV :: com.abc : xyz : 0.0.1-SNAOPSHOT is present in repositoryA and repositoryB. Want Maven settings to define in such a way, so-that maven only try to pull artifact xyz from repositoryA. In other words, wants repositoryA to be used only to pull xyz artifact or any artifact from com.abc group. To achieve same, an includes/excludes xml chunk can be defined under repository definition for repositoryB within settings.xml was: Let's say an artifact with GAV :: com.abc : xyz : 0.0.1-SNAOPSHOT is present in repositoryA and repositoryB. Want Maven settings to define in such a way, so-that maven only try to pull artifact xyz from repositoryA. To achieve same, an excludes xml chunk can be defined under repository definition for repositoryB within settings.xml > Maven to exclude list/wildcard of groupId's or artifactId's from particular > repository > -- > > Key: MNG-7461 > URL: https://issues.apache.org/jira/browse/MNG-7461 > Project: Maven > Issue Type: Improvement > Components: Settings >Reporter: Kapil Singal >Priority: Major > > Let's say an artifact with GAV :: com.abc : xyz : 0.0.1-SNAOPSHOT is present > in repositoryA and repositoryB. > Want Maven settings to define in such a way, so-that maven only try to pull > artifact xyz from repositoryA. > In other words, wants repositoryA to be used only to pull xyz artifact or any > artifact from com.abc group. > To achieve same, an includes/excludes xml chunk can be defined under > repository definition for repositoryB within settings.xml -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MNG-7461) Maven to exclude list/wildcard of groupId's or artifactId's from particular repository
[ https://issues.apache.org/jira/browse/MNG-7461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kapil Singal updated MNG-7461: -- Description: Let's say an artifact with GAV :: com.abc : xyz : 0.0.1-SNAOPSHOT is present in repositoryA and repositoryB. Want Maven settings to define in such a way, so-that maven only try to pull artifact xyz from repositoryA. To achieve same, an excludes xml chunk can be defined under repository definition for repositoryB within settings.xml was: Let's say an artifact with GAV :: com.abc : xyz : 0.0.1-SNAOPSHOT is present in repositoryA and repositoryB. Want Maven settings to define in such a way, so-that maven only try to pull artifact xyz from repositoryA, to achieve same there excludes xml chunk can be defined under repository definition for repositoryB within settings.xml > Maven to exclude list/wildcard of groupId's or artifactId's from particular > repository > -- > > Key: MNG-7461 > URL: https://issues.apache.org/jira/browse/MNG-7461 > Project: Maven > Issue Type: Improvement > Components: Settings >Reporter: Kapil Singal >Priority: Major > > Let's say an artifact with GAV :: com.abc : xyz : 0.0.1-SNAOPSHOT is present > in repositoryA and repositoryB. > Want Maven settings to define in such a way, so-that maven only try to pull > artifact xyz from repositoryA. > To achieve same, an excludes xml chunk can be defined under repository > definition for repositoryB within settings.xml -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MNG-7461) Maven to exclude list/wildcard of groupId's or artifactId's from particular repository
Kapil Singal created MNG-7461: - Summary: Maven to exclude list/wildcard of groupId's or artifactId's from particular repository Key: MNG-7461 URL: https://issues.apache.org/jira/browse/MNG-7461 Project: Maven Issue Type: Improvement Components: Settings Reporter: Kapil Singal Let's say an artifact with GAV :: com.abc : xyz : 0.0.1-SNAOPSHOT is present in repositoryA and repositoryB. Want Maven settings to define in such a way, so-that maven only try to pull artifact xyz from repositoryA, to achieve same there excludes xml chunk can be defined under repository definition for repositoryB within settings.xml -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2067) Improve site configuration
[
https://issues.apache.org/jira/browse/SUREFIRE-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521965#comment-17521965
]
Olivier Lamy commented on SUREFIRE-2067:
doh might be long time ago as I don't remember 🤣
but yeah I find this top bar very convenient (especially to navigate trough all
interesting reports 😜😜)
anyway I don't really have big preference (topbar is probably not really trendy
anymore now)
> Improve site configuration
> --
>
> Key: SUREFIRE-2067
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2067
> Project: Maven Surefire
> Issue Type: Improvement
> Components: documentation
>Reporter: Slawomir Jaranowski
>Priority: Major
>
> Configuration like: {{bannerLeft}}, {{bannerRight}}, skin version should be
> taken from parent.
> Currently we have old Maven logo on documentation site.
> We have also enabled {{topBar}} which is not enabled on other Maven project,
> so it is some of inconsistent.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2067) Improve site configuration
[
https://issues.apache.org/jira/browse/SUREFIRE-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521962#comment-17521962
]
Slawomir Jaranowski commented on SUREFIRE-2067:
---
[~hboutemy], [~olamy] does logo should be the same as on the other Maven sites?
> Improve site configuration
> --
>
> Key: SUREFIRE-2067
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2067
> Project: Maven Surefire
> Issue Type: Improvement
> Components: documentation
>Reporter: Slawomir Jaranowski
>Priority: Major
>
> Configuration like: {{bannerLeft}}, {{bannerRight}}, skin version should be
> taken from parent.
> Currently we have old Maven logo on documentation site.
> We have also enabled {{topBar}} which is not enabled on other Maven project,
> so it is some of inconsistent.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2067) Improve site configuration
[
https://issues.apache.org/jira/browse/SUREFIRE-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521960#comment-17521960
]
Herve Boutemy commented on SUREFIRE-2067:
-
it was [~olamy] who wanted to have some Surefire-specific look and feel,
particularly the topBar
but on banners and skin, I suppose they could basically be inherited from
parent, you're right
> Improve site configuration
> --
>
> Key: SUREFIRE-2067
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2067
> Project: Maven Surefire
> Issue Type: Improvement
> Components: documentation
>Reporter: Slawomir Jaranowski
>Priority: Major
>
> Configuration like: {{bannerLeft}}, {{bannerRight}}, skin version should be
> taken from parent.
> Currently we have old Maven logo on documentation site.
> We have also enabled {{topBar}} which is not enabled on other Maven project,
> so it is some of inconsistent.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MASFRES-53) Incomplete artifact in maven repository
[ https://issues.apache.org/jira/browse/MASFRES-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MASFRES-53. - Resolution: Invalid Go to https://issues.sonatype.org/browse/MVNCENTRAL > Incomplete artifact in maven repository > --- > > Key: MASFRES-53 > URL: https://issues.apache.org/jira/browse/MASFRES-53 > Project: Apache Maven Resource Bundles > Issue Type: Bug >Reporter: Peyton Thomas >Priority: Major > Attachments: ActivationV1_0_2.PNG > > > My organization is running into a failure due to an incomplete/corrupt > artifact. The artifact is javax:activation:1.0.2. We are using > [https://repo1.maven.org|https://repo1.maven.org/] to populate our central > repositories. When searching through the repository we've noticed the jar > file is missing for this version of javax.activation. I believe this artifact > needs to be deleted and pulled back into your repository. > > path to specific artifact: > [https://repo1.maven.org/maven2/javax/activation/activation/1.0.2/] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MASFRES-53) Incomplete artifact in maven repository
Peyton Thomas created MASFRES-53: Summary: Incomplete artifact in maven repository Key: MASFRES-53 URL: https://issues.apache.org/jira/browse/MASFRES-53 Project: Apache Maven Resource Bundles Issue Type: Bug Reporter: Peyton Thomas Attachments: ActivationV1_0_2.PNG My organization is running into a failure due to an incomplete/corrupt artifact. The artifact is javax:activation:1.0.2. We are using [https://repo1.maven.org|https://repo1.maven.org/] to populate our central repositories. When searching through the repository we've noticed the jar file is missing for this version of javax.activation. I believe this artifact needs to be deleted and pulled back into your repository. path to specific artifact: [https://repo1.maven.org/maven2/javax/activation/activation/1.0.2/] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-integration-testing] michael-o commented on pull request #141: [MNG-7404] Drop support for prefixless expressions
michael-o commented on PR #141: URL: https://github.com/apache/maven-integration-testing/pull/141#issuecomment-1098475975 Will pick up tomrrow -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-2072) Surefire retains too much heap in some case, leading to OutOfMemory
[ https://issues.apache.org/jira/browse/SUREFIRE-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521928#comment-17521928 ] Mickael Istria commented on SUREFIRE-2072: -- In general, caching some kB here and there can be a good idea, however I have the impression that with patch for SUREFIRE-1845, each test will consume 64kB of extra memory even if it actually only has a dozen of characters to cache (as it's the case for JDT tests). So most of the extra memory consumeption causing the OOM isn't even used at all. > Surefire retains too much heap in some case, leading to OutOfMemory > --- > > Key: SUREFIRE-2072 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2072 > Project: Maven Surefire > Issue Type: Bug >Reporter: Mickael Istria >Priority: Major > > Most likely since SuREFIRE-1845, every test execution can retain 64kB of RAM > (as cache). Which caching is welcome, this cannot scale with some big test > suites of several thousands of tests and cause OutOfMemoryError. > This is the case when running Eclipse JDT dom test suite, since > tycho-surefire-plugin started to adopt surefire 3.0.0.M6, as described in > https://github.com/eclipse/tycho/issues/879#issuecomment-1096454637 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (SUREFIRE-2072) Surefire retains too much heap in some case, leading to OutOfMemory
Mickael Istria created SUREFIRE-2072: Summary: Surefire retains too much heap in some case, leading to OutOfMemory Key: SUREFIRE-2072 URL: https://issues.apache.org/jira/browse/SUREFIRE-2072 Project: Maven Surefire Issue Type: Bug Reporter: Mickael Istria Most likely since SuREFIRE-1845, every test execution can retain 64kB of RAM (as cache). Which caching is welcome, this cannot scale with some big test suites of several thousands of tests and cause OutOfMemoryError. This is the case when running Eclipse JDT dom test suite, since tycho-surefire-plugin started to adopt surefire 3.0.0.M6, as described in https://github.com/eclipse/tycho/issues/879#issuecomment-1096454637 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1845) Fixed the performance of Utf8RecodingDeferredFileOutputStream as a bottleneck for the tests with logs
[ https://issues.apache.org/jira/browse/SUREFIRE-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521916#comment-17521916 ] Mickael Istria commented on SUREFIRE-1845: -- This change can too easily cause OutOfMemory for some cases, I'm going to open a separate ticket with details > Fixed the performance of Utf8RecodingDeferredFileOutputStream as a bottleneck > for the tests with logs > - > > Key: SUREFIRE-1845 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1845 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M6 > > > The fix would speed up the cache 8 times. > After we have applied fast TCP/IP encoder and decoder along with the fix for > this issue we have got fast Test3 in the integration test > ConsoleOutputIT#largerSoutThanMemory(), i.e. 0.44 seconds of the test exec > time from previous 8.8 seconds. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-5222) Maven 3 no longer logs warnings about deprecated plugin parameters.
[ https://issues.apache.org/jira/browse/MNG-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521781#comment-17521781 ] Hudson commented on MNG-5222: - Build failed in Jenkins: Maven » Maven TLP » maven » PR-712 #4 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-712/4/ > Maven 3 no longer logs warnings about deprecated plugin parameters. > --- > > Key: MNG-5222 > URL: https://issues.apache.org/jira/browse/MNG-5222 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.3 >Reporter: Christian Schulte >Assignee: Slawomir Jaranowski >Priority: Minor > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Providing a value for a deprecated plugin parameter, Maven 2.2.1 used to log > a warning. Currently Maven 3 does not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7454) Include resolver-transport-http in Maven
[ https://issues.apache.org/jira/browse/MNG-7454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521782#comment-17521782 ] Hudson commented on MNG-7454: - Build failed in Jenkins: Maven » Maven TLP » maven » PR-712 #4 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-712/4/ > Include resolver-transport-http in Maven > > > Key: MNG-7454 > URL: https://issues.apache.org/jira/browse/MNG-7454 > Project: Maven > Issue Type: New Feature > Components: Dependencies >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > > We should include maven-resolver-transport-http (along with existing > maven-resolver-transport-wagon) but retain Wagon as default transport, while > offer ability for users to use http transport to utilize new resolver > features like "smart checksums". > On positive side, this will finally get rid of shaded httpClient and > wagon-http-shaded as well. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-5222) Maven 3 no longer logs warnings about deprecated plugin parameters.
[ https://issues.apache.org/jira/browse/MNG-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521777#comment-17521777 ] Hudson commented on MNG-5222: - Build succeeded in Jenkins: Maven » Maven TLP » maven » PR-565 #13 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-565/13/ > Maven 3 no longer logs warnings about deprecated plugin parameters. > --- > > Key: MNG-5222 > URL: https://issues.apache.org/jira/browse/MNG-5222 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.3 >Reporter: Christian Schulte >Assignee: Slawomir Jaranowski >Priority: Minor > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Providing a value for a deprecated plugin parameter, Maven 2.2.1 used to log > a warning. Currently Maven 3 does not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7454) Include resolver-transport-http in Maven
[ https://issues.apache.org/jira/browse/MNG-7454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521770#comment-17521770 ] Hudson commented on MNG-7454: - Build unstable in Jenkins: Maven » Maven TLP » maven » PR-509 #13 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-509/13/ > Include resolver-transport-http in Maven > > > Key: MNG-7454 > URL: https://issues.apache.org/jira/browse/MNG-7454 > Project: Maven > Issue Type: New Feature > Components: Dependencies >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > > We should include maven-resolver-transport-http (along with existing > maven-resolver-transport-wagon) but retain Wagon as default transport, while > offer ability for users to use http transport to utilize new resolver > features like "smart checksums". > On positive side, this will finally get rid of shaded httpClient and > wagon-http-shaded as well. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-5222) Maven 3 no longer logs warnings about deprecated plugin parameters.
[ https://issues.apache.org/jira/browse/MNG-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521769#comment-17521769 ] Hudson commented on MNG-5222: - Build unstable in Jenkins: Maven » Maven TLP » maven » PR-509 #13 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-509/13/ > Maven 3 no longer logs warnings about deprecated plugin parameters. > --- > > Key: MNG-5222 > URL: https://issues.apache.org/jira/browse/MNG-5222 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.3 >Reporter: Christian Schulte >Assignee: Slawomir Jaranowski >Priority: Minor > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Providing a value for a deprecated plugin parameter, Maven 2.2.1 used to log > a warning. Currently Maven 3 does not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-5222) Maven 3 no longer logs warnings about deprecated plugin parameters.
[ https://issues.apache.org/jira/browse/MNG-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521747#comment-17521747 ] Hudson commented on MNG-5222: - Build unstable in Jenkins: Maven » Maven TLP » maven » PR-394 #14 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-394/14/ > Maven 3 no longer logs warnings about deprecated plugin parameters. > --- > > Key: MNG-5222 > URL: https://issues.apache.org/jira/browse/MNG-5222 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.3 >Reporter: Christian Schulte >Assignee: Slawomir Jaranowski >Priority: Minor > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Providing a value for a deprecated plugin parameter, Maven 2.2.1 used to log > a warning. Currently Maven 3 does not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-5222) Maven 3 no longer logs warnings about deprecated plugin parameters.
[ https://issues.apache.org/jira/browse/MNG-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521743#comment-17521743 ] Hudson commented on MNG-5222: - Build succeeded in Jenkins: Maven » Maven TLP » maven » PR-600 #13 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-600/13/ > Maven 3 no longer logs warnings about deprecated plugin parameters. > --- > > Key: MNG-5222 > URL: https://issues.apache.org/jira/browse/MNG-5222 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.3 >Reporter: Christian Schulte >Assignee: Slawomir Jaranowski >Priority: Minor > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Providing a value for a deprecated plugin parameter, Maven 2.2.1 used to log > a warning. Currently Maven 3 does not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7454) Include resolver-transport-http in Maven
[ https://issues.apache.org/jira/browse/MNG-7454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521744#comment-17521744 ] Hudson commented on MNG-7454: - Build succeeded in Jenkins: Maven » Maven TLP » maven » PR-600 #13 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-600/13/ > Include resolver-transport-http in Maven > > > Key: MNG-7454 > URL: https://issues.apache.org/jira/browse/MNG-7454 > Project: Maven > Issue Type: New Feature > Components: Dependencies >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > > We should include maven-resolver-transport-http (along with existing > maven-resolver-transport-wagon) but retain Wagon as default transport, while > offer ability for users to use http transport to utilize new resolver > features like "smart checksums". > On positive side, this will finally get rid of shaded httpClient and > wagon-http-shaded as well. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7454) Include resolver-transport-http in Maven
[ https://issues.apache.org/jira/browse/MNG-7454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521742#comment-17521742 ] Hudson commented on MNG-7454: - Build succeeded in Jenkins: Maven » Maven TLP » maven » PR-700 #8 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-700/8/ > Include resolver-transport-http in Maven > > > Key: MNG-7454 > URL: https://issues.apache.org/jira/browse/MNG-7454 > Project: Maven > Issue Type: New Feature > Components: Dependencies >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > > We should include maven-resolver-transport-http (along with existing > maven-resolver-transport-wagon) but retain Wagon as default transport, while > offer ability for users to use http transport to utilize new resolver > features like "smart checksums". > On positive side, this will finally get rid of shaded httpClient and > wagon-http-shaded as well. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-5222) Maven 3 no longer logs warnings about deprecated plugin parameters.
[ https://issues.apache.org/jira/browse/MNG-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521741#comment-17521741 ] Hudson commented on MNG-5222: - Build succeeded in Jenkins: Maven » Maven TLP » maven » PR-700 #8 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-700/8/ > Maven 3 no longer logs warnings about deprecated plugin parameters. > --- > > Key: MNG-5222 > URL: https://issues.apache.org/jira/browse/MNG-5222 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.3 >Reporter: Christian Schulte >Assignee: Slawomir Jaranowski >Priority: Minor > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Providing a value for a deprecated plugin parameter, Maven 2.2.1 used to log > a warning. Currently Maven 3 does not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MRESOLVER-251) Upgrade Redisson to 3.16.8
[ https://issues.apache.org/jira/browse/MRESOLVER-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MRESOLVER-251: - Summary: Upgrade Redisson to 3.16.8 (was: Upgrade Redission to 3.16.8) > Upgrade Redisson to 3.16.8 > -- > > Key: MRESOLVER-251 > URL: https://issues.apache.org/jira/browse/MRESOLVER-251 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 1.8.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MRESOLVER-251) Upgrade Redission to 3.16.8
Michael Osipov created MRESOLVER-251: Summary: Upgrade Redission to 3.16.8 Key: MRESOLVER-251 URL: https://issues.apache.org/jira/browse/MRESOLVER-251 Project: Maven Resolver Issue Type: Dependency upgrade Components: Resolver Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 1.8.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (MNG-7453) Upgrade Maven Resolver to 1.8.0
[ https://issues.apache.org/jira/browse/MNG-7453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521681#comment-17521681 ] Tamás Cservenák edited comment on MNG-7453 at 4/13/22 1:09 PM: --- PRs: * maven-3.9.x [https://github.com/apache/maven/pull/718] * maven-4.x.x [https://github.com/apache/maven/pull/719] was (Author: cstamas): PRs: * maven-3.9.x [https://github.com/apache/maven/pull/718] * master [https://github.com/apache/maven/pull/719] > Upgrade Maven Resolver to 1.8.0 > --- > > Key: MNG-7453 > URL: https://issues.apache.org/jira/browse/MNG-7453 > Project: Maven > Issue Type: Dependency upgrade > Components: Artifacts and Repositories >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > > Maven Resolver 1.8 will bring multiple improvements in many area: extensible > checksum algorithms, provided checksum, ability for signature resolution, > smart checksum, new BF collection along with "old" DF collector, etc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7453) Upgrade Maven Resolver to 1.8.0
[ https://issues.apache.org/jira/browse/MNG-7453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521681#comment-17521681 ] Tamás Cservenák commented on MNG-7453: -- PRs: * maven-3.9.x [https://github.com/apache/maven/pull/718] * master [https://github.com/apache/maven/pull/719] > Upgrade Maven Resolver to 1.8.0 > --- > > Key: MNG-7453 > URL: https://issues.apache.org/jira/browse/MNG-7453 > Project: Maven > Issue Type: Dependency upgrade > Components: Artifacts and Repositories >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > > Maven Resolver 1.8 will bring multiple improvements in many area: extensible > checksum algorithms, provided checksum, ability for signature resolution, > smart checksum, new BF collection along with "old" DF collector, etc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] cstamas commented on a diff in pull request #719: [MNG-7453] Upgrade Maven Resolver to 1.8.0 in maven-4.x
cstamas commented on code in PR #719:
URL: https://github.com/apache/maven/pull/719#discussion_r849458128
##
pom.xml:
##
@@ -45,6 +45,19 @@ under the License.
https://maven.apache.org/ref/${project.version}/
2001
+
+
+ repository.apache.org
+ https://repository.apache.org/content/repositories/snapshots
+
+false
+
+
+true
+
+
+
Review Comment:
eh, missed it :) I assumed maven build does not allow snapshots for some
reason (and CI builds w/ snapshots would fail)
--
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 #719: [MNG-7453] Upgrade Maven Resolver to 1.8.0 in maven-4.x
slawekjaranowski commented on code in PR #719:
URL: https://github.com/apache/maven/pull/719#discussion_r849455129
##
pom.xml:
##
@@ -45,6 +45,19 @@ under the License.
https://maven.apache.org/ref/${project.version}/
2001
+
+
+ repository.apache.org
+ https://repository.apache.org/content/repositories/snapshots
+
+false
+
+
+true
+
+
+
Review Comment:
There is in ASF pom
https://github.com/apache/maven-apache-parent/blob/master/pom.xml#L110-L129
Is it not the same?
--
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, #719: [MNG-7453] Upgrade Maven Resolver to 1.8.0 in maven-4.x
cstamas opened a new pull request, #719: URL: https://github.com/apache/maven/pull/719 Note: current repository change in POM is ONLY to make CI run ITs. This PR is placeholder until maven-resolver 1.8.0 is released, but until then let's see ITs at least. --- https://issues.apache.org/jira/browse/MNG-7453 -- 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, #718: [MNG-7453] Upgrade Maven Resolver to 1.8.0
cstamas opened a new pull request, #718: URL: https://github.com/apache/maven/pull/718 Note: current repository change in POM is ONLY to make CI run ITs. This PR is placeholder until maven-resolver 1.8.0 is released, but until then let's see ITs at least. --- https://issues.apache.org/jira/browse/MNG-7453 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-2068) System.out.println() causes BufferOverflow
[
https://issues.apache.org/jira/browse/SUREFIRE-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521661#comment-17521661
]
Jan Waś commented on SUREFIRE-2068:
---
I'm seeing this in a module that uses TestNG 6.10, when trying to upgrade to
3.0.0-M6 in [the Trino project:|https://github.com/trinodb/trino]
{noformat}
Caused by: java.nio.BufferOverflowException
at java.base/java.nio.Buffer.nextPutIndex(Buffer.java:666)
at java.base/java.nio.HeapByteBuffer.put(HeapByteBuffer.java:200)
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.testng.TestNGReporter.writeTestOutput(TestNGReporter.java:240)
at
org.apache.maven.surefire.api.report.ConsoleOutputCapture$ForwardingPrintStream.println(ConsoleOutputCapture.java:144)
at
io.trino.execution.TestingPageSourceProvider.(TestingPageSourceProvider.java:41)
at
io.trino.execution.TaskTestUtils.createTestingPlanner(TaskTestUtils.java:107)
at io.trino.execution.TestSqlTask.(TestSqlTask.java:95)
... 33 more{noformat}
> System.out.println() causes BufferOverflow
> --
>
> Key: SUREFIRE-2068
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2068
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, JUnit 5.x support
>Affects Versions: 3.0.0-M6
>Reporter: Steven Pearce
>Priority: Minor
> Attachments: surefire-buffer-overflow.zip
>
>
> Using the SUREFIRE-1614 minimal project as a starting point I've added the
> line
> {noformat}
> System.out.println();
> {noformat}
> at line 16 of CustomRunner.class
> I've also updated the dependancies, but it mostly remains the same.
> I've attached the reproducible example
> Executing with `./mvnw -Pjunit5 test` or `./mvnw -Pjunit4 test` both produce
> the same output.
> Downgrading to 3.0.0-M5 no longer causes the issue.
> This will now trigger the exception
> {noformat}
> java.nio.BufferOverflowException
> at java.base/java.nio.Buffer.nextPutIndex(Buffer.java:722)
> at java.base/java.nio.HeapByteBuffer.put(HeapByteBuffer.java:209)
> 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.junitplatform.RunListenerAdapter.writeTestOutput(RunListenerAdapter.java:379)
> at
> org.apache.maven.surefire.api.report.ConsoleOutputCapture$ForwardingPrintStream.println(ConsoleOutputCapture.java:144)
> at com.example.demo.CustomRunner.createTestClass(CustomRunner.java:16)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (MNG-7453) Upgrade Maven Resolver to 1.8.0
[ https://issues.apache.org/jira/browse/MNG-7453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák reassigned MNG-7453: Assignee: Tamás Cservenák > Upgrade Maven Resolver to 1.8.0 > --- > > Key: MNG-7453 > URL: https://issues.apache.org/jira/browse/MNG-7453 > Project: Maven > Issue Type: Dependency upgrade > Components: Artifacts and Repositories >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > > Maven Resolver 1.8 will bring multiple improvements in many area: extensible > checksum algorithms, provided checksum, ability for signature resolution, > smart checksum, new BF collection along with "old" DF collector, etc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-surefire] zoltanmeze commented on a diff in pull request #519: After surefire 2058
zoltanmeze commented on code in PR #519:
URL: https://github.com/apache/maven-surefire/pull/519#discussion_r849436470
##
surefire-api/src/main/java/org/apache/maven/surefire/api/stream/AbstractStreamDecoder.java:
##
@@ -305,32 +313,24 @@ private String readString( @Nonnull final Memento
memento, @Nonnegative final in
memento.getDecoder().reset();
final CharBuffer output = memento.getCharBuffer();
( (Buffer) output ).clear();
-final ByteBuffer input = memento.getByteBuffer();
final List strings = new ArrayList<>();
int countDecodedBytes = 0;
for ( boolean endOfInput = false; !endOfInput; )
{
-final int bytesToRead = totalBytes - countDecodedBytes;
+final int bytesToRead = totalBytes - countDecodedBytes; // our
wish to read bytes as much as possible
read( memento, bytesToRead );
-int bytesToDecode = min( input.remaining(), bytesToRead );
+final ByteBuffer input = memento.getByteBuffer();
+int bytesToDecode = min( input.remaining(), bytesToRead ); // our
guarantee of available bytes in buffer
final boolean isLastChunk = bytesToDecode == bytesToRead;
endOfInput = countDecodedBytes + bytesToDecode >= totalBytes;
-do
-{
-boolean endOfChunk = output.remaining() >= bytesToRead;
-boolean endOfOutput = isLastChunk && endOfChunk;
-int readInputBytes = decodeString( memento.getDecoder(),
input, output, bytesToDecode, endOfOutput,
-memento.getLine().getPositionByteBuffer() );
-bytesToDecode -= readInputBytes;
-countDecodedBytes += readInputBytes;
-}
-while ( isLastChunk && bytesToDecode > 0 && output.hasRemaining()
);
-
-if ( isLastChunk || !output.hasRemaining() )
-{
-strings.add( ( (Buffer) output ).flip().toString() );
-( (Buffer) output ).clear();
-}
+boolean endOfChunk = output.remaining() >= bytesToRead;
+boolean endOfOutput = isLastChunk && endOfChunk;
+int readInputBytes = decodeString( memento.getDecoder(), input,
output, bytesToDecode, endOfOutput,
+memento.getLine().getPositionByteBuffer() );
+countDecodedBytes += readInputBytes;
+strings.add( ( (Buffer) output ).flip().toString() );
+( (Buffer) output ).clear();
+memento.getLine().setPositionByteBuffer( 0 );
Review Comment:
What's the reason of resetting line position here?
Will give this branch a try later. Maybe compare events dump before and
after on single test runs, and just see if larger projects have no other
issues.
I think I already tried with removed do-while once, because it was
suspicious at first look. But didn't want to change anything else in #518 , but
my guess was that that wile condition is never true.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7055) Using MINSTALL/DEPLOY 3.0.0-M1+ does not write plugin information into maven-metadata.xml
[
https://issues.apache.org/jira/browse/MNG-7055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521657#comment-17521657
]
Tamás Cservenák commented on MNG-7055:
--
Backported as [https://github.com/apache/maven/pull/691,] locally tested and
all ok. Please bless it (pretty much same change as already scrutinized
original PR).
> Using MINSTALL/DEPLOY 3.0.0-M1+ does not write plugin information into
> maven-metadata.xml
> -
>
> Key: MNG-7055
> URL: https://issues.apache.org/jira/browse/MNG-7055
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, Plugins and Lifecycle
>Reporter: Elliotte Rusty Harold
>Assignee: Tamás Cservenák
>Priority: Blocker
> Fix For: 3.9.0, 3.9.0-candidate, 4.0.0-alpha-1, 4.0.0
>
>
> Copying [~michael-o]'s comment from mailing list on HEAD with Maven core ITs:
> https://markmail.org/message/ggcioupa6yaet4xe#query:+page:1+mid:noyp5d3iyclrfgyp+state:results
> {noformat}[ERROR] Tests run: 834, Failures: 0, Errors: 1, Skipped: 0, Time
> elapsed: 287.261 s <<< FAILURE! - in org.apache.maven.it.IntegrationTestSuite
> [ERROR]
> testitMNG3372(org.apache.maven.it.MavenITmng3372DirectInvocationOfPluginsTest)
> Time elapsed: 1.5 s <<< ERROR!
> org.apache.maven.it.VerificationException:
> Exit code was non-zero: 1; command line and log =
> /var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/apache-maven/bin/mvn
> --global-settings
> /var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/test-classes/settings.xml
> -s
> /var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3372/direct-using-prefix/settings.xml
> -e --batch-mode
> -Dmaven.repo.local=/net/home/osipovmi/var/Projekte/maven-integration-testing/repo
> mng3372:test
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for
> org.apache.maven.its.mng3372:project:jar:1.0-SNAPSHOT
> [WARNING] Version not locked for default bindings plugins [maven-clean-plugin,
> maven-resources-plugin, maven-jar-plugin, maven-compiler-plugin,
> maven-surefire-plugin, maven-install-plugin, maven-deploy-plugin,
> maven-site-plugin], you should define versions in pluginManagement section of
> your pom.xml or parent @ line 6, column 14
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> [WARNING]
> [INFO] Downloading from central:
> file:target/null/org/apache/maven/its/mng3372/maven-metadata.xml
> [INFO] Downloading from central:
> file:target/null/org/apache/maven/plugins/maven-metadata.xml
> [INFO] Downloading from central:
> file:target/null/org/codehaus/mojo/maven-metadata.xml
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.056 s
> [INFO] Finished at: 2020-06-04T22:03:01+02:00
> [INFO]
>
> [ERROR] No plugin found for prefix 'mng3372' in the current project and in the
> plugin groups [org.apache.maven.its.mng3372, org.apache.maven.plugins,
> org.codehaus.mojo] available from the repositories [local
> (/net/home/osipovmi/var/Projekte/maven-integration-testing/repo), central
> (file:target/null)] -> [Help 1]
> org.apache.maven.plugin.prefix.NoPluginFoundForPrefixException: No plugin
> found
> for prefix 'mng3372' in the current project and in the plugin groups
> [org.apache.maven.its.mng3372, org.apache.maven.plugins, org.codehaus.mojo]
> available from the repositories [local
> (/net/home/osipovmi/var/Projekte/maven-integration-testing/repo), central
> (file:target/null)]
> at
> org.apache.maven.plugin.prefix.internal.DefaultPluginPrefixResolver.resolve(DefaultPluginPrefixResolver.java:98)
> at
> org.apache.maven.lifecycle.internal.MojoDescriptorCreator.findPluginForPrefix(MojoDescriptorCreator.java:269)
> at
> org.apache.maven.lifecycle.internal.MojoDescriptorCreator.getMojoDescript{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MRESOLVER-250) Usage of descriptors map in DataPool prevents gargabe collection
[
https://issues.apache.org/jira/browse/MRESOLVER-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521639#comment-17521639
]
Hudson commented on MRESOLVER-250:
--
Build succeeded in Jenkins: Maven » Maven TLP » maven-resolver » master #21
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-resolver/job/master/21/
> Usage of descriptors map in DataPool prevents gargabe collection
>
>
> Key: MRESOLVER-250
> URL: https://issues.apache.org/jira/browse/MRESOLVER-250
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
> Environment: Linux, Java 11
>Reporter: Frank Upgang
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 1.8.0
>
> Attachments: image-2022-04-12-16-36-19-783.png,
> image-2022-04-12-16-36-49-903.png, image-2022-04-13-12-35-15-582.png
>
>
> While resolving a lot of rather huge dependency trees in my application I
> observed a high heap consumption by
> {_}org.eclipse.aether.internal.impl.collect.DataPool{_}.
> The _DataPool_ holds _Descriptor_ references in a {_}WeakHashMap{_}.
> Unfortunately, the key is indirectly referenced by the value - thus is is
> never eligible for garbage collection.
> The key is _an Artifact_ taken from the {_}ArtifactDescriptorRequest{_}.
> The value is an _ArtifactDescriptorResult_ which references the _Artifact_
> (key) and the {_}ArtifactDescriptorRequest{_}.
> To fix this the value should be wrapped in a _WeakReference_ or
> {_}SoftReference{_}.
> This is what the _ObjectPools_ does which is used by the _DataPool_ for
> _Artifacts_ and {_}Dependencies{_}.
>
> My use case is an application that indexes the dependency trees of all our
> services. Therefore there is a lot of dependency resolution when building the
> index.
> I implemented a workaround by wrapping the value in a WeakReference. The
> memory consumption is significantly lower afterwards as shown by the attached
> screenshots.
>
> If desired, I would create a pull request, but I haven't set up a maven
> workspace yet.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MRESOLVER-250) Usage of descriptors map in DataPool prevents gargabe collection
[
https://issues.apache.org/jira/browse/MRESOLVER-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák closed MRESOLVER-250.
-
> Usage of descriptors map in DataPool prevents gargabe collection
>
>
> Key: MRESOLVER-250
> URL: https://issues.apache.org/jira/browse/MRESOLVER-250
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
> Environment: Linux, Java 11
>Reporter: Frank Upgang
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 1.8.0
>
> Attachments: image-2022-04-12-16-36-19-783.png,
> image-2022-04-12-16-36-49-903.png, image-2022-04-13-12-35-15-582.png
>
>
> While resolving a lot of rather huge dependency trees in my application I
> observed a high heap consumption by
> {_}org.eclipse.aether.internal.impl.collect.DataPool{_}.
> The _DataPool_ holds _Descriptor_ references in a {_}WeakHashMap{_}.
> Unfortunately, the key is indirectly referenced by the value - thus is is
> never eligible for garbage collection.
> The key is _an Artifact_ taken from the {_}ArtifactDescriptorRequest{_}.
> The value is an _ArtifactDescriptorResult_ which references the _Artifact_
> (key) and the {_}ArtifactDescriptorRequest{_}.
> To fix this the value should be wrapped in a _WeakReference_ or
> {_}SoftReference{_}.
> This is what the _ObjectPools_ does which is used by the _DataPool_ for
> _Artifacts_ and {_}Dependencies{_}.
>
> My use case is an application that indexes the dependency trees of all our
> services. Therefore there is a lot of dependency resolution when building the
> index.
> I implemented a workaround by wrapping the value in a WeakReference. The
> memory consumption is significantly lower afterwards as shown by the attached
> screenshots.
>
> If desired, I would create a pull request, but I haven't set up a maven
> workspace yet.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (MRESOLVER-250) Usage of descriptors map in DataPool prevents gargabe collection
[
https://issues.apache.org/jira/browse/MRESOLVER-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák resolved MRESOLVER-250.
---
Resolution: Fixed
> Usage of descriptors map in DataPool prevents gargabe collection
>
>
> Key: MRESOLVER-250
> URL: https://issues.apache.org/jira/browse/MRESOLVER-250
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
> Environment: Linux, Java 11
>Reporter: Frank Upgang
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 1.8.0
>
> Attachments: image-2022-04-12-16-36-19-783.png,
> image-2022-04-12-16-36-49-903.png, image-2022-04-13-12-35-15-582.png
>
>
> While resolving a lot of rather huge dependency trees in my application I
> observed a high heap consumption by
> {_}org.eclipse.aether.internal.impl.collect.DataPool{_}.
> The _DataPool_ holds _Descriptor_ references in a {_}WeakHashMap{_}.
> Unfortunately, the key is indirectly referenced by the value - thus is is
> never eligible for garbage collection.
> The key is _an Artifact_ taken from the {_}ArtifactDescriptorRequest{_}.
> The value is an _ArtifactDescriptorResult_ which references the _Artifact_
> (key) and the {_}ArtifactDescriptorRequest{_}.
> To fix this the value should be wrapped in a _WeakReference_ or
> {_}SoftReference{_}.
> This is what the _ObjectPools_ does which is used by the _DataPool_ for
> _Artifacts_ and {_}Dependencies{_}.
>
> My use case is an application that indexes the dependency trees of all our
> services. Therefore there is a lot of dependency resolution when building the
> index.
> I implemented a workaround by wrapping the value in a WeakReference. The
> memory consumption is significantly lower afterwards as shown by the attached
> screenshots.
>
> If desired, I would create a pull request, but I haven't set up a maven
> workspace yet.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-resolver] cstamas merged pull request #166: [MRESOLVER-250] Wrap DataPool descriptors into weak refs
cstamas merged PR #166: URL: https://github.com/apache/maven-resolver/pull/166 -- 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 #691: [MNG-7055] Fix G level metadata handling (#555)
cstamas commented on PR #691: URL: https://github.com/apache/maven/pull/691#issuecomment-1097938264 Verified locally the PR, all ok. @michael-o or @gnodet please review -- 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-7447) Several Improvements by using Stream API
[ https://issues.apache.org/jira/browse/MNG-7447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521631#comment-17521631 ] Hudson commented on MNG-7447: - Build succeeded in Jenkins: Maven » Maven TLP » maven » PR-691 #8 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-691/8/ > Several Improvements by using Stream API > > > Key: MNG-7447 > URL: https://issues.apache.org/jira/browse/MNG-7447 > Project: Maven > Issue Type: Sub-task >Affects Versions: 3.9.0, 4.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Major > Fix For: 3.9.0, 4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-5222) Maven 3 no longer logs warnings about deprecated plugin parameters.
[ https://issues.apache.org/jira/browse/MNG-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521632#comment-17521632 ] Hudson commented on MNG-5222: - Build succeeded in Jenkins: Maven » Maven TLP » maven » PR-691 #8 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-691/8/ > Maven 3 no longer logs warnings about deprecated plugin parameters. > --- > > Key: MNG-5222 > URL: https://issues.apache.org/jira/browse/MNG-5222 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.3 >Reporter: Christian Schulte >Assignee: Slawomir Jaranowski >Priority: Minor > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Providing a value for a deprecated plugin parameter, Maven 2.2.1 used to log > a warning. Currently Maven 3 does not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7432) [REGRESSION] Resolver session contains non-MavenWorkspaceReader
[ https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521630#comment-17521630 ] Hudson commented on MNG-7432: - Build succeeded in Jenkins: Maven » Maven TLP » maven » PR-691 #8 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-691/8/ > [REGRESSION] Resolver session contains non-MavenWorkspaceReader > --- > > Key: MNG-7432 > URL: https://issues.apache.org/jira/browse/MNG-7432 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Falko Modler >Assignee: Tamás Cservenák >Priority: Critical > Fix For: 3.8.6, 3.9.0, 4.0.0 > > > As Resolver session contains non-MavenWorkspaceReader, the reactor models > (already resolved w/ profiles applied) are re-built when using Resolver > within Mojo, instead to get them via ReactorReader as expected. The rebuilt > models will lack explicit (-P on CLI) profiles applied, as resolver itself is > not maven aware, hence there is no way to "tell" resolver to apply them. > Building reactor models w/ profiles applied is NOT done using resolver, but > by Maven when loading up reactor, as profiles are NOT applied for downstream > transitive dependencies (see discussion on MNG-1388 why). > --- > The README of the following reproducer says it all: > https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation > Initially discussed here: > https://github.com/quarkusio/quarkus/pull/24285#issuecomment-1067368625 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7441) Update Version of Logback to Address CVE-2021-42550
[
https://issues.apache.org/jira/browse/MNG-7441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521629#comment-17521629
]
Hudson commented on MNG-7441:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » PR-691 #8
See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-691/8/
> Update Version of Logback to Address CVE-2021-42550
> ---
>
> Key: MNG-7441
> URL: https://issues.apache.org/jira/browse/MNG-7441
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.8.5
>Reporter: Mac Hale
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 3.8.6, 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> [CVE-2021-42550|https://nvd.nist.gov/vuln/detail/CVE-2021-42550] is present
> in Logback versions 1.2.7 and earlier. Maven uses v 1.2.1. Please update to
> Logback 1.2.9, which includes a fix as per
> [https://jira.qos.ch/browse/LOGBACK-1591|[https://jira.qos.ch/browse/LOGBACK-1591].]
> I see ch.qos.logback 1.2.1 in {{./pom.xml}} and ch.qos.logback without a
> version specified in {{./maven-embedder/pom.xml}}
> But I'm no expert on this code base so it's possible there are other
> versioned references.
> Edit: One could argue, as the Logback team has done, that the CVE is
> unimportant since in order to exploit it one must already have compromised
> the system. However, security scanners pick this up as an issue, causing
> unnecessary work and justifications.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7454) Include resolver-transport-http in Maven
[ https://issues.apache.org/jira/browse/MNG-7454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521633#comment-17521633 ] Hudson commented on MNG-7454: - Build succeeded in Jenkins: Maven » Maven TLP » maven » PR-691 #8 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-691/8/ > Include resolver-transport-http in Maven > > > Key: MNG-7454 > URL: https://issues.apache.org/jira/browse/MNG-7454 > Project: Maven > Issue Type: New Feature > Components: Dependencies >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > > We should include maven-resolver-transport-http (along with existing > maven-resolver-transport-wagon) but retain Wagon as default transport, while > offer ability for users to use http transport to utilize new resolver > features like "smart checksums". > On positive side, this will finally get rid of shaded httpClient and > wagon-http-shaded as well. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7452) Remove JDK7 run on Maven 3.9.X Branch
[ https://issues.apache.org/jira/browse/MNG-7452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521628#comment-17521628 ] Hudson commented on MNG-7452: - Build succeeded in Jenkins: Maven » Maven TLP » maven » PR-691 #8 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-691/8/ > Remove JDK7 run on Maven 3.9.X Branch > - > > Key: MNG-7452 > URL: https://issues.apache.org/jira/browse/MNG-7452 > Project: Maven > Issue Type: Task >Affects Versions: 3.9.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.9.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-5222) Maven 3 no longer logs warnings about deprecated plugin parameters.
[ https://issues.apache.org/jira/browse/MNG-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521627#comment-17521627 ] Hudson commented on MNG-5222: - Build succeeded in Jenkins: Maven » Maven TLP » maven » master #30 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/30/ > Maven 3 no longer logs warnings about deprecated plugin parameters. > --- > > Key: MNG-5222 > URL: https://issues.apache.org/jira/browse/MNG-5222 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.3 >Reporter: Christian Schulte >Assignee: Slawomir Jaranowski >Priority: Minor > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Providing a value for a deprecated plugin parameter, Maven 2.2.1 used to log > a warning. Currently Maven 3 does not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7454) Include resolver-transport-http in Maven
[ https://issues.apache.org/jira/browse/MNG-7454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521626#comment-17521626 ] Hudson commented on MNG-7454: - Build succeeded in Jenkins: Maven » Maven TLP » maven » master #30 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/30/ > Include resolver-transport-http in Maven > > > Key: MNG-7454 > URL: https://issues.apache.org/jira/browse/MNG-7454 > Project: Maven > Issue Type: New Feature > Components: Dependencies >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > > We should include maven-resolver-transport-http (along with existing > maven-resolver-transport-wagon) but retain Wagon as default transport, while > offer ability for users to use http transport to utilize new resolver > features like "smart checksums". > On positive side, this will finally get rid of shaded httpClient and > wagon-http-shaded as well. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7454) Include resolver-transport-http in Maven
[ https://issues.apache.org/jira/browse/MNG-7454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521619#comment-17521619 ] Hudson commented on MNG-7454: - Build succeeded in Jenkins: Maven » Maven TLP » maven » maven-3.9.x #16 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.9.x/16/ > Include resolver-transport-http in Maven > > > Key: MNG-7454 > URL: https://issues.apache.org/jira/browse/MNG-7454 > Project: Maven > Issue Type: New Feature > Components: Dependencies >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > > We should include maven-resolver-transport-http (along with existing > maven-resolver-transport-wagon) but retain Wagon as default transport, while > offer ability for users to use http transport to utilize new resolver > features like "smart checksums". > On positive side, this will finally get rid of shaded httpClient and > wagon-http-shaded as well. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (MNG-7454) Include resolver-transport-http in Maven
[ https://issues.apache.org/jira/browse/MNG-7454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák closed MNG-7454. > Include resolver-transport-http in Maven > > > Key: MNG-7454 > URL: https://issues.apache.org/jira/browse/MNG-7454 > Project: Maven > Issue Type: New Feature > Components: Dependencies >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > > We should include maven-resolver-transport-http (along with existing > maven-resolver-transport-wagon) but retain Wagon as default transport, while > offer ability for users to use http transport to utilize new resolver > features like "smart checksums". > On positive side, this will finally get rid of shaded httpClient and > wagon-http-shaded as well. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (MNG-7454) Include resolver-transport-http in Maven
[ https://issues.apache.org/jira/browse/MNG-7454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák resolved MNG-7454. -- Resolution: Fixed > Include resolver-transport-http in Maven > > > Key: MNG-7454 > URL: https://issues.apache.org/jira/browse/MNG-7454 > Project: Maven > Issue Type: New Feature > Components: Dependencies >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > > We should include maven-resolver-transport-http (along with existing > maven-resolver-transport-wagon) but retain Wagon as default transport, while > offer ability for users to use http transport to utilize new resolver > features like "smart checksums". > On positive side, this will finally get rid of shaded httpClient and > wagon-http-shaded as well. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] cstamas merged pull request #711: [MNG-7454] Include resolver-transport-http in Maven master
cstamas merged PR #711: URL: https://github.com/apache/maven/pull/711 -- 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 merged pull request #710: [MNG-7454] Include resolver-transport-http in Maven 3.9.x
cstamas merged PR #710: URL: https://github.com/apache/maven/pull/710 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7454) Include resolver-transport-http in Maven
[ https://issues.apache.org/jira/browse/MNG-7454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák updated MNG-7454: - Fix Version/s: 4.0.0-alpha-1 > Include resolver-transport-http in Maven > > > Key: MNG-7454 > URL: https://issues.apache.org/jira/browse/MNG-7454 > Project: Maven > Issue Type: New Feature > Components: Dependencies >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > > We should include maven-resolver-transport-http (along with existing > maven-resolver-transport-wagon) but retain Wagon as default transport, while > offer ability for users to use http transport to utilize new resolver > features like "smart checksums". > On positive side, this will finally get rid of shaded httpClient and > wagon-http-shaded as well. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (MRESOLVER-250) Usage of descriptors map in DataPool prevents gargabe collection
[
https://issues.apache.org/jira/browse/MRESOLVER-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák reassigned MRESOLVER-250:
-
Assignee: Tamás Cservenák
> Usage of descriptors map in DataPool prevents gargabe collection
>
>
> Key: MRESOLVER-250
> URL: https://issues.apache.org/jira/browse/MRESOLVER-250
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
> Environment: Linux, Java 11
>Reporter: Frank Upgang
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 1.8.0
>
> Attachments: image-2022-04-12-16-36-19-783.png,
> image-2022-04-12-16-36-49-903.png, image-2022-04-13-12-35-15-582.png
>
>
> While resolving a lot of rather huge dependency trees in my application I
> observed a high heap consumption by
> {_}org.eclipse.aether.internal.impl.collect.DataPool{_}.
> The _DataPool_ holds _Descriptor_ references in a {_}WeakHashMap{_}.
> Unfortunately, the key is indirectly referenced by the value - thus is is
> never eligible for garbage collection.
> The key is _an Artifact_ taken from the {_}ArtifactDescriptorRequest{_}.
> The value is an _ArtifactDescriptorResult_ which references the _Artifact_
> (key) and the {_}ArtifactDescriptorRequest{_}.
> To fix this the value should be wrapped in a _WeakReference_ or
> {_}SoftReference{_}.
> This is what the _ObjectPools_ does which is used by the _DataPool_ for
> _Artifacts_ and {_}Dependencies{_}.
>
> My use case is an application that indexes the dependency trees of all our
> services. Therefore there is a lot of dependency resolution when building the
> index.
> I implemented a workaround by wrapping the value in a WeakReference. The
> memory consumption is significantly lower afterwards as shown by the attached
> screenshots.
>
> If desired, I would create a pull request, but I haven't set up a maven
> workspace yet.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MRESOLVER-250) Usage of descriptors map in DataPool prevents gargabe collection
[
https://issues.apache.org/jira/browse/MRESOLVER-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MRESOLVER-250:
--
Fix Version/s: 1.8.0
> Usage of descriptors map in DataPool prevents gargabe collection
>
>
> Key: MRESOLVER-250
> URL: https://issues.apache.org/jira/browse/MRESOLVER-250
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
> Environment: Linux, Java 11
>Reporter: Frank Upgang
>Priority: Major
> Fix For: 1.8.0
>
> Attachments: image-2022-04-12-16-36-19-783.png,
> image-2022-04-12-16-36-49-903.png, image-2022-04-13-12-35-15-582.png
>
>
> While resolving a lot of rather huge dependency trees in my application I
> observed a high heap consumption by
> {_}org.eclipse.aether.internal.impl.collect.DataPool{_}.
> The _DataPool_ holds _Descriptor_ references in a {_}WeakHashMap{_}.
> Unfortunately, the key is indirectly referenced by the value - thus is is
> never eligible for garbage collection.
> The key is _an Artifact_ taken from the {_}ArtifactDescriptorRequest{_}.
> The value is an _ArtifactDescriptorResult_ which references the _Artifact_
> (key) and the {_}ArtifactDescriptorRequest{_}.
> To fix this the value should be wrapped in a _WeakReference_ or
> {_}SoftReference{_}.
> This is what the _ObjectPools_ does which is used by the _DataPool_ for
> _Artifacts_ and {_}Dependencies{_}.
>
> My use case is an application that indexes the dependency trees of all our
> services. Therefore there is a lot of dependency resolution when building the
> index.
> I implemented a workaround by wrapping the value in a WeakReference. The
> memory consumption is significantly lower afterwards as shown by the attached
> screenshots.
>
> If desired, I would create a pull request, but I haven't set up a maven
> workspace yet.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MRESOLVER-250) Usage of descriptors map in DataPool prevents gargabe collection
[
https://issues.apache.org/jira/browse/MRESOLVER-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521612#comment-17521612
]
Tamás Cservenák commented on MRESOLVER-250:
---
Thanks for testing this. [~michael-o] pls review the PR.
> Usage of descriptors map in DataPool prevents gargabe collection
>
>
> Key: MRESOLVER-250
> URL: https://issues.apache.org/jira/browse/MRESOLVER-250
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
> Environment: Linux, Java 11
>Reporter: Frank Upgang
>Priority: Major
> Attachments: image-2022-04-12-16-36-19-783.png,
> image-2022-04-12-16-36-49-903.png, image-2022-04-13-12-35-15-582.png
>
>
> While resolving a lot of rather huge dependency trees in my application I
> observed a high heap consumption by
> {_}org.eclipse.aether.internal.impl.collect.DataPool{_}.
> The _DataPool_ holds _Descriptor_ references in a {_}WeakHashMap{_}.
> Unfortunately, the key is indirectly referenced by the value - thus is is
> never eligible for garbage collection.
> The key is _an Artifact_ taken from the {_}ArtifactDescriptorRequest{_}.
> The value is an _ArtifactDescriptorResult_ which references the _Artifact_
> (key) and the {_}ArtifactDescriptorRequest{_}.
> To fix this the value should be wrapped in a _WeakReference_ or
> {_}SoftReference{_}.
> This is what the _ObjectPools_ does which is used by the _DataPool_ for
> _Artifacts_ and {_}Dependencies{_}.
>
> My use case is an application that indexes the dependency trees of all our
> services. Therefore there is a lot of dependency resolution when building the
> index.
> I implemented a workaround by wrapping the value in a WeakReference. The
> memory consumption is significantly lower afterwards as shown by the attached
> screenshots.
>
> If desired, I would create a pull request, but I haven't set up a maven
> workspace yet.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MRESOLVER-250) Usage of descriptors map in DataPool prevents gargabe collection
[
https://issues.apache.org/jira/browse/MRESOLVER-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521608#comment-17521608
]
Frank Upgang commented on MRESOLVER-250:
Thanks for fixing this!
Just tested the 1.8.0-SNAPSHOT containing the fix and I can verify the memory
improvement in my use case.
!image-2022-04-13-12-35-15-582.png!
This run resolves about 250 dependency trees (verbose) containing some large
monolithic applications.
(We index all dependency trees to immediately answer questions like "Who is
still using unsupported versions of spring?" or "Which services are affected by
log4shell or spring4shell?")
> Usage of descriptors map in DataPool prevents gargabe collection
>
>
> Key: MRESOLVER-250
> URL: https://issues.apache.org/jira/browse/MRESOLVER-250
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
> Environment: Linux, Java 11
>Reporter: Frank Upgang
>Priority: Major
> Attachments: image-2022-04-12-16-36-19-783.png,
> image-2022-04-12-16-36-49-903.png, image-2022-04-13-12-35-15-582.png
>
>
> While resolving a lot of rather huge dependency trees in my application I
> observed a high heap consumption by
> {_}org.eclipse.aether.internal.impl.collect.DataPool{_}.
> The _DataPool_ holds _Descriptor_ references in a {_}WeakHashMap{_}.
> Unfortunately, the key is indirectly referenced by the value - thus is is
> never eligible for garbage collection.
> The key is _an Artifact_ taken from the {_}ArtifactDescriptorRequest{_}.
> The value is an _ArtifactDescriptorResult_ which references the _Artifact_
> (key) and the {_}ArtifactDescriptorRequest{_}.
> To fix this the value should be wrapped in a _WeakReference_ or
> {_}SoftReference{_}.
> This is what the _ObjectPools_ does which is used by the _DataPool_ for
> _Artifacts_ and {_}Dependencies{_}.
>
> My use case is an application that indexes the dependency trees of all our
> services. Therefore there is a lot of dependency resolution when building the
> index.
> I implemented a workaround by wrapping the value in a WeakReference. The
> memory consumption is significantly lower afterwards as shown by the attached
> screenshots.
>
> If desired, I would create a pull request, but I haven't set up a maven
> workspace yet.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MRESOLVER-250) Usage of descriptors map in DataPool prevents gargabe collection
[
https://issues.apache.org/jira/browse/MRESOLVER-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank Upgang updated MRESOLVER-250:
---
Attachment: image-2022-04-13-12-35-15-582.png
> Usage of descriptors map in DataPool prevents gargabe collection
>
>
> Key: MRESOLVER-250
> URL: https://issues.apache.org/jira/browse/MRESOLVER-250
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
> Environment: Linux, Java 11
>Reporter: Frank Upgang
>Priority: Major
> Attachments: image-2022-04-12-16-36-19-783.png,
> image-2022-04-12-16-36-49-903.png, image-2022-04-13-12-35-15-582.png
>
>
> While resolving a lot of rather huge dependency trees in my application I
> observed a high heap consumption by
> {_}org.eclipse.aether.internal.impl.collect.DataPool{_}.
> The _DataPool_ holds _Descriptor_ references in a {_}WeakHashMap{_}.
> Unfortunately, the key is indirectly referenced by the value - thus is is
> never eligible for garbage collection.
> The key is _an Artifact_ taken from the {_}ArtifactDescriptorRequest{_}.
> The value is an _ArtifactDescriptorResult_ which references the _Artifact_
> (key) and the {_}ArtifactDescriptorRequest{_}.
> To fix this the value should be wrapped in a _WeakReference_ or
> {_}SoftReference{_}.
> This is what the _ObjectPools_ does which is used by the _DataPool_ for
> _Artifacts_ and {_}Dependencies{_}.
>
> My use case is an application that indexes the dependency trees of all our
> services. Therefore there is a lot of dependency resolution when building the
> index.
> I implemented a workaround by wrapping the value in a WeakReference. The
> memory consumption is significantly lower afterwards as shown by the attached
> screenshots.
>
> If desired, I would create a pull request, but I haven't set up a maven
> workspace yet.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] zoltanmeze commented on a diff in pull request #518: [SUREFIRE-2058] - Corrupted STDOUT by directly writing to native stream in forked JVM 1 with UTF-8 console logging
zoltanmeze commented on code in PR #518:
URL: https://github.com/apache/maven-surefire/pull/518#discussion_r849297428
##
surefire-api/src/test/java/org/apache/maven/surefire/api/stream/AbstractStreamDecoderTest.java:
##
@@ -258,6 +258,56 @@ public void shouldReadString() throws Exception
.isEqualTo( "0123456789" );
}
+@Test
+public void shouldReadStringOverflowOnNewLine() throws Exception
+{
+StringBuilder s = new StringBuilder( 1025 );
+for ( int i = 0; i < 10; i++ )
+{
+s.append( PATTERN1 );
+}
+s.append( PATTERN1, 0, 23 );
+s.append( "\u00FA\n" ); // 2-bytes encoded character + LF
+
+Channel channel = new Channel( s.toString().getBytes( UTF_8 ),
s.length() );
+
+Mock thread = new Mock( channel, new MockForkNodeArguments(),
+Collections.emptyMap() );
Review Comment:
Sure. Other test methods are also using explicit type arguments, so just
used the same way.
For consistency replaced in all places in this class, see
[0b1c564](https://github.com/apache/maven-surefire/pull/518/commits/0b1c564779d924901c9bd3f88482fe1f33964bdb).
--
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] zoltanmeze commented on a diff in pull request #518: [SUREFIRE-2058] - Corrupted STDOUT by directly writing to native stream in forked JVM 1 with UTF-8 console logging
zoltanmeze commented on code in PR #518:
URL: https://github.com/apache/maven-surefire/pull/518#discussion_r849297428
##
surefire-api/src/test/java/org/apache/maven/surefire/api/stream/AbstractStreamDecoderTest.java:
##
@@ -258,6 +258,56 @@ public void shouldReadString() throws Exception
.isEqualTo( "0123456789" );
}
+@Test
+public void shouldReadStringOverflowOnNewLine() throws Exception
+{
+StringBuilder s = new StringBuilder( 1025 );
+for ( int i = 0; i < 10; i++ )
+{
+s.append( PATTERN1 );
+}
+s.append( PATTERN1, 0, 23 );
+s.append( "\u00FA\n" ); // 2-bytes encoded character + LF
+
+Channel channel = new Channel( s.toString().getBytes( UTF_8 ),
s.length() );
+
+Mock thread = new Mock( channel, new MockForkNodeArguments(),
+Collections.emptyMap() );
Review Comment:
Sure. Other test methods are also using explicit type arguments, so just
used the same way.
For consistency replaced in all places in this class.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] rfscholte commented on pull request #703: New API with immutable model
rfscholte commented on PR #703: URL: https://github.com/apache/maven/pull/703#issuecomment-1097726493 My wish is that for a future Maven release we have maven-xx-api and maven-xx-spi modules (I'm not sure if we need a single huge api module, or multiple small ones) , so plugins and extensions don't need to compile with maven-core. With this we can give them a module name, so developers that want to use a module descriptor can do so. However, that implies no split packages! Keep that in mind when choosing the package names. -- 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] (MRESOLVER-250) Usage of descriptors map in DataPool prevents gargabe collection
[
https://issues.apache.org/jira/browse/MRESOLVER-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521546#comment-17521546
]
Tamás Cservenák commented on MRESOLVER-250:
---
Locally measured on projects like Maven itself or resolver itself (all OSS),
minor memory improvement can be measured. The change is good, but again, just
like with BF/DF collection, we have no use cases and projects of size as
[~fupgang] has I guess...
> Usage of descriptors map in DataPool prevents gargabe collection
>
>
> Key: MRESOLVER-250
> URL: https://issues.apache.org/jira/browse/MRESOLVER-250
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
> Environment: Linux, Java 11
>Reporter: Frank Upgang
>Priority: Major
> Attachments: image-2022-04-12-16-36-19-783.png,
> image-2022-04-12-16-36-49-903.png
>
>
> While resolving a lot of rather huge dependency trees in my application I
> observed a high heap consumption by
> {_}org.eclipse.aether.internal.impl.collect.DataPool{_}.
> The _DataPool_ holds _Descriptor_ references in a {_}WeakHashMap{_}.
> Unfortunately, the key is indirectly referenced by the value - thus is is
> never eligible for garbage collection.
> The key is _an Artifact_ taken from the {_}ArtifactDescriptorRequest{_}.
> The value is an _ArtifactDescriptorResult_ which references the _Artifact_
> (key) and the {_}ArtifactDescriptorRequest{_}.
> To fix this the value should be wrapped in a _WeakReference_ or
> {_}SoftReference{_}.
> This is what the _ObjectPools_ does which is used by the _DataPool_ for
> _Artifacts_ and {_}Dependencies{_}.
>
> My use case is an application that indexes the dependency trees of all our
> services. Therefore there is a lot of dependency resolution when building the
> index.
> I implemented a workaround by wrapping the value in a WeakReference. The
> memory consumption is significantly lower afterwards as shown by the attached
> screenshots.
>
> If desired, I would create a pull request, but I haven't set up a maven
> workspace yet.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-mvnd] gnodet merged pull request #617: Use err stream when purging logs during a build, fixes #604
gnodet merged PR #617: URL: https://github.com/apache/maven-mvnd/pull/617 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] gnodet closed issue #604: Log purging goes to stdout breaking scripts
gnodet closed issue #604: Log purging goes to stdout breaking scripts URL: https://github.com/apache/maven-mvnd/issues/604 -- 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] gnodet commented on pull request #703: New API with immutable model
gnodet commented on PR #703: URL: https://github.com/apache/maven/pull/703#issuecomment-1097715774 > First question... Do we want to have a cycles between packages and interfaces? > eg: > `org.apache.maven.api. Session` needs `org.apache.maven.api.services.ArtifactDeployer` > and `ArtifactDeployer` needs `Session`. The cycle has been removed. -- 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] gnodet commented on pull request #713: [MNG-7455] Use a single session object during the whole build
gnodet commented on PR #713: URL: https://github.com/apache/maven/pull/713#issuecomment-1097689941 > @gnodet alone you are right but with the 3 menrionned hacks it works. Only thing we are qure as of today is TL or ITL does not work so we must find something else I fear. I'm really not following. The problem raised by [7347](https://issues.apache.org/jira/browse/MNG-7347) is that components annotated with `@SessionScope` should be reused during the duration of the session (i.e. the reactor build). That was not the case (and I also found out the fix is not sufficient I think). So we don't really want to discriminate components, it's really the opposite, they should be shared. So it's really independent of any classloading mechanism imho. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MDEP-794) It is not respecting the includeScope and excludeScope
[
https://issues.apache.org/jira/browse/MDEP-794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521529#comment-17521529
]
Cristiano Gavião commented on MDEP-794:
---
Hi [~sjaranowski] , strangely I didn't receive a notification for your comment.
I've added a new archive with a simplified project. I've used the
'hbase-client' because it has a system dependency that is being copied.
> It is not respecting the includeScope and excludeScope
> --
>
> Key: MDEP-794
> URL: https://issues.apache.org/jira/browse/MDEP-794
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: copy-dependencies
>Affects Versions: 3.2.0
> Environment: Both Windows and Linux
>Reporter: Cristiano Gavião
>Priority: Critical
> Attachments: Deps.7z, Deps2.7z
>
>
> I'm using the copyDependencies to build a distribution package and I'm
> getting junit.jar and others on it.
> {code:java}
>
> maven-dependency-plugin
> 3.2.0
>
> sources,javadoc,full,pom
> system
> compile
>
> {code}
>
> {code:java}
> [DEBUG] Configuring mojo
> org.apache.maven.plugins:maven-dependency-plugin:3.2.0:copy-dependencies from
> plugin realm
> ClassRealm[plugin>org.apache.maven.plugins:maven-dependency-plugin:3.2.0,
> parent: sun.misc.Launcher$AppClassLoader@18b4aac2]
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-dependency-plugin:3.2.0:copy-dependencies'
> with basic configurator -->
> [DEBUG] (f) addParentPoms = false
> [DEBUG] (s) copyPom = false
> [DEBUG] (f) excludeArtifactIds = jdk.tools
> [DEBUG] (f) excludeClassifiers = sources,javadoc,full,pom
> [DEBUG] (f) excludeScope = system
> [DEBUG] (f) excludeTransitive = false
> [DEBUG] (s) failOnMissingClassifierArtifact = false
> [DEBUG] (f) includeScope = compile
> [DEBUG] (s) markersDirectory =
> C:\Users\cristianoga\git-code\p-stripping\target\dependency-maven-plugin-markers
> [DEBUG] (f) outputAbsoluteArtifactFilename = false
> [DEBUG] (s) outputDirectory =
> C:\Users\cristianoga\git-code\p-stripping\target\dependency
> [DEBUG] (f) overWriteIfNewer = true
> [DEBUG] (f) overWriteReleases = false
> [DEBUG] (f) overWriteSnapshots = false
> [DEBUG] (s) prependGroupId = false {code}
> {code:java}
> [INFO] Copying junit-4.13.2.jar to
> C:\Users\cristianoga\git-code\p-stripping\target\dependency\junit-4.13.2.jar
> [INFO] Copying hamcrest-core-1.3.jar to
> C:\Users\cristianoga\git-code\p-stripping\target\dependency\hamcrest-core-1.3.jar
> [INFO] Copying mockito-core-3.12.4.jar to
> C:\Users\cristianoga\git-code\p-stripping\target\dependency\mockito-core-3.12.4.jar
> [INFO] Copying byte-buddy-1.11.13.jar to
> C:\Users\cristianoga\git-code\p-stripping\target\dependency\byte-buddy-1.11.13.jar
> [INFO] Copying byte-buddy-agent-1.11.13.jar to
> C:\Users\cristianoga\git-code\p-stripping\target\dependency\byte-buddy-agent-1.11.13.jar
> [INFO] Copying objenesis-3.2.jar to
> C:\Users\cristianoga\git-code\p-stripping\target\dependency\objenesis-3.2.jar
> [INFO] Copying dbunit-2.7.2.jar to
> C:\Users\cristianoga\git-code\p-stripping\target\dependency\dbunit-2.7.2.jar
> [INFO] Copying h2-1.4.200.jar to
> C:\Users\cristianoga\git-code\p-stripping\target\dependency\h2-1.4.200.jar
> [INFO] Copying assertj-core-3.21.0.jar to
> C:\Users\cristianoga\git-code\p-stripping\target\dependency\assertj-core-3.21.0.jar
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-doxia-converter] slachiewicz merged pull request #25: Bump jacoco-maven-plugin from 0.8.7 to 0.8.8
slachiewicz merged PR #25: URL: https://github.com/apache/maven-doxia-converter/pull/25 -- 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] (MDEP-794) It is not respecting the includeScope and excludeScope
[
https://issues.apache.org/jira/browse/MDEP-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cristiano Gavião updated MDEP-794:
--
Attachment: Deps2.7z
> It is not respecting the includeScope and excludeScope
> --
>
> Key: MDEP-794
> URL: https://issues.apache.org/jira/browse/MDEP-794
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: copy-dependencies
>Affects Versions: 3.2.0
> Environment: Both Windows and Linux
>Reporter: Cristiano Gavião
>Priority: Critical
> Attachments: Deps.7z, Deps2.7z
>
>
> I'm using the copyDependencies to build a distribution package and I'm
> getting junit.jar and others on it.
> {code:java}
>
> maven-dependency-plugin
> 3.2.0
>
> sources,javadoc,full,pom
> system
> compile
>
> {code}
>
> {code:java}
> [DEBUG] Configuring mojo
> org.apache.maven.plugins:maven-dependency-plugin:3.2.0:copy-dependencies from
> plugin realm
> ClassRealm[plugin>org.apache.maven.plugins:maven-dependency-plugin:3.2.0,
> parent: sun.misc.Launcher$AppClassLoader@18b4aac2]
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-dependency-plugin:3.2.0:copy-dependencies'
> with basic configurator -->
> [DEBUG] (f) addParentPoms = false
> [DEBUG] (s) copyPom = false
> [DEBUG] (f) excludeArtifactIds = jdk.tools
> [DEBUG] (f) excludeClassifiers = sources,javadoc,full,pom
> [DEBUG] (f) excludeScope = system
> [DEBUG] (f) excludeTransitive = false
> [DEBUG] (s) failOnMissingClassifierArtifact = false
> [DEBUG] (f) includeScope = compile
> [DEBUG] (s) markersDirectory =
> C:\Users\cristianoga\git-code\p-stripping\target\dependency-maven-plugin-markers
> [DEBUG] (f) outputAbsoluteArtifactFilename = false
> [DEBUG] (s) outputDirectory =
> C:\Users\cristianoga\git-code\p-stripping\target\dependency
> [DEBUG] (f) overWriteIfNewer = true
> [DEBUG] (f) overWriteReleases = false
> [DEBUG] (f) overWriteSnapshots = false
> [DEBUG] (s) prependGroupId = false {code}
> {code:java}
> [INFO] Copying junit-4.13.2.jar to
> C:\Users\cristianoga\git-code\p-stripping\target\dependency\junit-4.13.2.jar
> [INFO] Copying hamcrest-core-1.3.jar to
> C:\Users\cristianoga\git-code\p-stripping\target\dependency\hamcrest-core-1.3.jar
> [INFO] Copying mockito-core-3.12.4.jar to
> C:\Users\cristianoga\git-code\p-stripping\target\dependency\mockito-core-3.12.4.jar
> [INFO] Copying byte-buddy-1.11.13.jar to
> C:\Users\cristianoga\git-code\p-stripping\target\dependency\byte-buddy-1.11.13.jar
> [INFO] Copying byte-buddy-agent-1.11.13.jar to
> C:\Users\cristianoga\git-code\p-stripping\target\dependency\byte-buddy-agent-1.11.13.jar
> [INFO] Copying objenesis-3.2.jar to
> C:\Users\cristianoga\git-code\p-stripping\target\dependency\objenesis-3.2.jar
> [INFO] Copying dbunit-2.7.2.jar to
> C:\Users\cristianoga\git-code\p-stripping\target\dependency\dbunit-2.7.2.jar
> [INFO] Copying h2-1.4.200.jar to
> C:\Users\cristianoga\git-code\p-stripping\target\dependency\h2-1.4.200.jar
> [INFO] Copying assertj-core-3.21.0.jar to
> C:\Users\cristianoga\git-code\p-stripping\target\dependency\assertj-core-3.21.0.jar
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
