date:20220310



pzygielo commented on pull request #95:
URL: 
https://github.com/apache/maven-shared-utils/pull/95#issuecomment-1064843016


   May I ask for review, please?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-surefire] slawekjaranowski commented on pull request #485: [SUREFIRE-2036] Fix JUnit 5 with configured provider



slawekjaranowski commented on pull request #485:
URL: https://github.com/apache/maven-surefire/pull/485#issuecomment-1064840915


   @roxspring thanks for collaboration


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Closed] (SUREFIRE-2036) Regression: 3.0.0-M5 fails with configured JUnit 5 provider



 [ 
https://issues.apache.org/jira/browse/SUREFIRE-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Slawomir Jaranowski closed SUREFIRE-2036.
-
Resolution: Fixed

> Regression: 3.0.0-M5 fails with configured JUnit 5 provider
> ---
>
> Key: SUREFIRE-2036
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2036
> Project: Maven Surefire
>  Issue Type: Bug
>Reporter: Robert James Oxspring
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> SUREFIRE-2033 breaks the automatic configuration of the JUnit 5 provider when 
> {{junit-platform-runner}} happens to be in the classpath, but additionally 
> manual override of this misconfiguration is broken too and results in a 
> {{{}NullPointerException{}}}.
> Specifically, using [https://github.com/apache/maven-surefire/pull/485]:
> {code:java}
> % mvn test -f surefire-its/src/test/resources/surefire-2036 
> -Dsurefire.version=3.0.0-M5 -X
> ...
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time:  1.022 s
> [INFO] Finished at: 2022-03-09T22:18:36Z
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (default-test) 
> on project surefire-2036: Execution default-test of goal 
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed.: 
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test 
> (default-test) on project surefire-2036: Execution default-test of goal 
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed.
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:215)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:156)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:148)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:81)
>     at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  (SingleThreadedBuilder.java:56)
>     at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:128)
>     at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
>     at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
>     at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
>     at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
>     at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
>     at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
>     at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>     at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
>     at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke (Method.java:566)
>     at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
>     at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
>     at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
>     at org.codehaus.plexus.classworlds.launcher.Launcher.main 
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
> default-test of goal 
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed.
>     at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:148)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:210)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:156)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:148)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:81)
>     at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  (SingleThreadedBuilder.java:56)
>     at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:128)
>

[jira] [Assigned] (SUREFIRE-2036) Regression: 3.0.0-M5 fails with configured JUnit 5 provider



 [ 
https://issues.apache.org/jira/browse/SUREFIRE-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Slawomir Jaranowski reassigned SUREFIRE-2036:
-

Assignee: Slawomir Jaranowski

> Regression: 3.0.0-M5 fails with configured JUnit 5 provider
> ---
>
> Key: SUREFIRE-2036
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2036
> Project: Maven Surefire
>  Issue Type: Bug
>Reporter: Robert James Oxspring
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> SUREFIRE-2033 breaks the automatic configuration of the JUnit 5 provider when 
> {{junit-platform-runner}} happens to be in the classpath, but additionally 
> manual override of this misconfiguration is broken too and results in a 
> {{{}NullPointerException{}}}.
> Specifically, using [https://github.com/apache/maven-surefire/pull/485]:
> {code:java}
> % mvn test -f surefire-its/src/test/resources/surefire-2036 
> -Dsurefire.version=3.0.0-M5 -X
> ...
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time:  1.022 s
> [INFO] Finished at: 2022-03-09T22:18:36Z
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (default-test) 
> on project surefire-2036: Execution default-test of goal 
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed.: 
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test 
> (default-test) on project surefire-2036: Execution default-test of goal 
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed.
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:215)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:156)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:148)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:81)
>     at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  (SingleThreadedBuilder.java:56)
>     at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:128)
>     at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
>     at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
>     at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
>     at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
>     at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
>     at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
>     at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>     at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
>     at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke (Method.java:566)
>     at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
>     at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
>     at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
>     at org.codehaus.plexus.classworlds.launcher.Launcher.main 
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
> default-test of goal 
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed.
>     at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:148)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:210)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:156)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:148)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:81)
>     at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  (SingleThreadedBuilder.java:56)
>     at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (Lifecyc

[GitHub] [maven-surefire] slawekjaranowski merged pull request #485: [SUREFIRE-2036] Fix JUnit 5 with configured provider



slawekjaranowski merged pull request #485:
URL: https://github.com/apache/maven-surefire/pull/485


   


-- 
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] olamy commented on pull request #485: [SUREFIRE-2036] Fix JUnit 5 with configured provider



olamy commented on pull request #485:
URL: https://github.com/apache/maven-surefire/pull/485#issuecomment-1064833320


   >  once this is merged, could you push a snapshot to repository.apache.org? 
I would like to test it with our build early. Thanks
   
   @dantran once is merged to master branch it's automatically deployed.
   


-- 
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-jxr] slawekjaranowski opened a new pull request #52: [JXR-165] Upgrade Maven Reporting to 3.1.0



slawekjaranowski opened a new pull request #52:
URL: https://github.com/apache/maven-jxr/pull/52


   Following this checklist to help us incorporate your 
   contribution quickly and easily:
   
- [x] Make sure there is a [JIRA 
issue](https://issues.apache.org/jira/browse/JXR) filed 
  for the change (usually before you start working on it).  Trivial 
changes like typos do not 
  require a JIRA issue.  Your pull request should address just this 
issue, without 
  pulling in other changes.
- [ ] Each commit in the pull request should have a meaningful subject line 
and body.
- [x] Format the pull request title like `[JXR-XXX] - Fixes bug in 
ApproximateQuantiles`,
  where you replace `JXR-XXX` with the appropriate JIRA issue. Best 
practice
  is to use the JIRA issue title in the pull request title and in the 
first line of the 
  commit message.
- [ ] Write a pull request description that is detailed enough to 
understand what the pull request does, how, and why.
- [x] Run `mvn clean verify` to make sure basic checks pass. A more 
thorough check will 
  be performed on your pull request automatically.
- [x] You have run the integration tests successfully (`mvn -Prun-its clean 
verify`).
   
   If your pull request is about ~20 lines of code you don't need to sign an
   [Individual Contributor License 
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
   please ask on the developers list.
   
   To make clear that you license your contribution under 
   the [Apache License Version 2.0, January 
2004](http://www.apache.org/licenses/LICENSE-2.0)
   you have to acknowledge this by using the following check-box.
   
- [x] I hereby declare this contribution to be licenced under the [Apache 
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
   
- [x] In any other case, please file an [Apache Individual Contributor 
License Agreement](https://www.apache.org/licenses/icla.pdf).
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MPLUGIN-394) Report-Mojo doesn't respect input encoding

2022-03-10 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MPLUGIN-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504742#comment-17504742
 ] 

ASF GitHub Bot commented on MPLUGIN-394:


hboutemy commented on a change in pull request #73:
URL: https://github.com/apache/maven-plugin-tools/pull/73#discussion_r824427199



##
File path: 
maven-plugin-plugin/src/it/mplugin-394_report-encoding/invoker.properties
##
@@ -0,0 +1,18 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+# 
+#   http://www.apache.org/licenses/LICENSE-2.0
+# 
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+
+invoker.goals = -Dfile.encoding=CP1252 plugin:report

Review comment:
   honestly, we don't really write ITs for such encoding issues: there is 
no chance of regression at plugin level, only base encoding-aware XML reading 
class is well tested
   so IMHO, don't worry too much, eventually remove the IT that was done if 
it's not useful: it was done based on good principles, but life is life on such 
feature




-- 
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


> Report-Mojo doesn't respect input encoding
> --
>
> Key: MPLUGIN-394
> URL: https://issues.apache.org/jira/browse/MPLUGIN-394
> Project: Maven Plugin Tools
>  Issue Type: Bug
>  Components: Plugin Plugin
>Affects Versions: 3.6.4
>Reporter: Sebastian Kühn
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.7.0
>
>
> {{plugin:report}} reads the Plugin-XML-File with with the platform encoding 
> instead of the specified input encoding. This results in an broken generated 
> XDoc and finally Site.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[GitHub] [maven-plugin-tools] hboutemy commented on a change in pull request #73: [MPLUGIN-394] Respect input encoding



hboutemy commented on a change in pull request #73:
URL: https://github.com/apache/maven-plugin-tools/pull/73#discussion_r824427199



##
File path: 
maven-plugin-plugin/src/it/mplugin-394_report-encoding/invoker.properties
##
@@ -0,0 +1,18 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+# 
+#   http://www.apache.org/licenses/LICENSE-2.0
+# 
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+
+invoker.goals = -Dfile.encoding=CP1252 plugin:report

Review comment:
   honestly, we don't really write ITs for such encoding issues: there is 
no chance of regression at plugin level, only base encoding-aware XML reading 
class is well tested
   so IMHO, don't worry too much, eventually remove the IT that was done if 
it's not useful: it was done based on good principles, but life is life on such 
feature




-- 
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] laeubi commented on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build



laeubi commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064784340


   Just for references as I recently added support for project-scoped 
WorkspaceReaders, if you like to support such components one needs to add 
explicit support for them similar to:
   
   
https://github.com/apache/maven/blob/97c1e4b4aa73f5851801fdf5e17f013dd46a6b3e/maven-core/src/main/java/org/apache/maven/DefaultMaven.java#L371-L379
   
https://github.com/apache/maven/blob/97c1e4b4aa73f5851801fdf5e17f013dd46a6b3e/maven-core/src/main/java/org/apache/maven/DefaultMaven.java#L507-L542
   
   as you see, the calling code should also be aware that there are *multiple* 
items and has to handle this (combine, call in a row, throw exception ...).


-- 
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] laeubi commented on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build



laeubi commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064779022


   > but other think defining extensions in the pom is preferable
   
   Just in case you don't know it (and to save you from to much hassle) it is 
no longer required to define core-extensions in `lib/ext` you can simply define 
them in `.mvn/extensions.xml` of the project, and I think that's what you 
actually try to arcive by your "master-project-classloader" see here for the 
documentation:
   https://maven.apache.org/ref/3.8.4/maven-embedder/core-extensions.html
   
   You can take a look here for an example of the tycho-build extension that is 
a core-extension:
   
https://github.com/eclipse/tycho/tree/master/tycho-its/projects/reactor.makeBehaviour


-- 
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-help-plugin] dependabot[bot] closed pull request #48: Bump maven-project-info-reports-plugin from 3.1.2 to 3.2.1



dependabot[bot] closed pull request #48:
URL: https://github.com/apache/maven-help-plugin/pull/48


   


-- 
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-help-plugin] dependabot[bot] commented on pull request #48: Bump maven-project-info-reports-plugin from 3.1.2 to 3.2.1



dependabot[bot] commented on pull request #48:
URL: https://github.com/apache/maven-help-plugin/pull/48#issuecomment-1064754525


   Superseded by #53.


-- 
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-help-plugin] dependabot[bot] opened a new pull request #53: Bump maven-project-info-reports-plugin from 3.1.2 to 3.2.2



dependabot[bot] opened a new pull request #53:
URL: https://github.com/apache/maven-help-plugin/pull/53


   Bumps 
[maven-project-info-reports-plugin](https://github.com/apache/maven-project-info-reports-plugin)
 from 3.1.2 to 3.2.2.
   
   Commits
   
   https://github.com/apache/maven-project-info-reports-plugin/commit/ca84755a9d1f58f6bd39e70457fb0d36ce3755c4";>ca84755
 [maven-release-plugin] prepare release 
maven-project-info-reports-plugin-3.2.2
   https://github.com/apache/maven-project-info-reports-plugin/commit/d28e98b8cfedbe179a1017d1a221871919841415";>d28e98b
 [MPIR-413] Plugin repositories defined in project are not used by plugin 
mana...
   https://github.com/apache/maven-project-info-reports-plugin/commit/99bfaef54bbff120317a7adfb7ca9cf0f883075c";>99bfaef
 [MPIR-414] Upgrade Maven Reporting API/Impl to 3.1.0
   https://github.com/apache/maven-project-info-reports-plugin/commit/d1bd10325e2cddf1cdf41f799d1407282006e067";>d1bd103
 Upgrade Maven Site Plugin for IT to 3.11.0
   https://github.com/apache/maven-project-info-reports-plugin/commit/547314f7cd71bad658ecad07a8195e8bd5e5dbcc";>547314f
 Replace usage of deprecated expressions
   https://github.com/apache/maven-project-info-reports-plugin/commit/517662c10b1e817a91c11f8433f3c832f5ad1601";>517662c
 [maven-release-plugin] prepare for next development iteration
   https://github.com/apache/maven-project-info-reports-plugin/commit/8c25c66593f488f6609910b95ae2b246c196d734";>8c25c66
 [maven-release-plugin] prepare release 
maven-project-info-reports-plugin-3.2.1
   https://github.com/apache/maven-project-info-reports-plugin/commit/d85aec37c385d64196f7db5c3c27b400b46032ca";>d85aec3
 [MPIR-412] Dependency report generates non-well-formed output if the POM of 
a...
   https://github.com/apache/maven-project-info-reports-plugin/commit/3c155a8231fac8b018c257d6dbe6bff0902633a2";>3c155a8
 [maven-release-plugin] prepare for next development iteration
   https://github.com/apache/maven-project-info-reports-plugin/commit/b130e220569301f89c58bfd10bf9de36efa20b1e";>b130e22
 [maven-release-plugin] prepare release 
maven-project-info-reports-plugin-3.2.0
   Additional commits viewable in https://github.com/apache/maven-project-info-reports-plugin/compare/maven-project-info-reports-plugin-3.1.2...maven-project-info-reports-plugin-3.2.2";>compare
 view
   
   
   
   
   
   [![Dependabot compatibility 
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=org.apache.maven.plugins:maven-project-info-reports-plugin&package-manager=maven&previous-version=3.1.2&new-version=3.2.2)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
   
   Dependabot will resolve any conflicts with this PR as long as you don't 
alter it yourself. You can also trigger a rebase manually by commenting 
`@dependabot rebase`.
   
   [//]: # (dependabot-automerge-start)
   [//]: # (dependabot-automerge-end)
   
   ---
   
   
   Dependabot commands and options
   
   
   You can trigger Dependabot actions by commenting on this PR:
   - `@dependabot rebase` will rebase this PR
   - `@dependabot recreate` will recreate this PR, overwriting any edits that 
have been made to it
   - `@dependabot merge` will merge this PR after your CI passes on it
   - `@dependabot squash and merge` will squash and merge this PR after your CI 
passes on it
   - `@dependabot cancel merge` will cancel a previously requested merge and 
block automerging
   - `@dependabot reopen` will reopen this PR if it is closed
   - `@dependabot close` will close this PR and stop Dependabot recreating it. 
You can achieve the same result by closing it manually
   - `@dependabot ignore this major version` will close this PR and stop 
Dependabot creating any more for this major version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this minor version` will close this PR and stop 
Dependabot creating any more for this minor version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this dependency` will close this PR and stop 
Dependabot creating any more for this dependency (unless you reopen the PR or 
upgrade to it yourself)
   
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-jlink-plugin] dependabot[bot] commented on pull request #91: Bump mockito-core from 4.2.0 to 4.3.1



dependabot[bot] commented on pull request #91:
URL: 
https://github.com/apache/maven-jlink-plugin/pull/91#issuecomment-1064753692


   Superseded by #99.


-- 
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-jlink-plugin] dependabot[bot] closed pull request #91: Bump mockito-core from 4.2.0 to 4.3.1



dependabot[bot] closed pull request #91:
URL: https://github.com/apache/maven-jlink-plugin/pull/91


   


-- 
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-jlink-plugin] dependabot[bot] opened a new pull request #99: Bump mockito-core from 4.2.0 to 4.4.0



dependabot[bot] opened a new pull request #99:
URL: https://github.com/apache/maven-jlink-plugin/pull/99


   Bumps [mockito-core](https://github.com/mockito/mockito) from 4.2.0 to 4.4.0.
   
   Release notes
   Sourced from https://github.com/mockito/mockito/releases";>mockito-core's 
releases.
   
   v4.4.0
   Changelog generated 
by https://github.com/shipkit/shipkit-changelog";>Shipkit Changelog 
Gradle Plugin
   4.4.0
   
   2022-03-08 - https://github.com/mockito/mockito/compare/v4.3.1...v4.4.0";>16 
commit(s) by Andrew Kozel, Brice Dutheil, Jean-Baptiste Mille, Mirko 
Alicastro, dependabot[bot]
   Bump groovy from 3.0.9 to 3.0.10 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2586";>#2586)](https://github-redirect.dependabot.com/mockito/mockito/pull/2586";>mockito/mockito#2586)
   Bump google-java-format from 1.14.0 to 1.15.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2585";>#2585)](https://github-redirect.dependabot.com/mockito/mockito/pull/2585";>mockito/mockito#2585)
   Bump actions/checkout from 2.4.0 to 3 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2582";>#2582)](https://github-redirect.dependabot.com/mockito/mockito/pull/2582";>mockito/mockito#2582)
   Bump shipkit-auto-version from 1.1.19 to 1.1.20 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2580";>#2580)](https://github-redirect.dependabot.com/mockito/mockito/pull/2580";>mockito/mockito#2580)
   Bump biz.aQute.bnd.builder from 6.1.0 to 6.2.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2579";>#2579)](https://github-redirect.dependabot.com/mockito/mockito/pull/2579";>mockito/mockito#2579)
   Bump biz.aQute.bnd.gradle from 6.1.0 to 6.2.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2578";>#2578)](https://github-redirect.dependabot.com/mockito/mockito/pull/2578";>mockito/mockito#2578)
   Adds a Google Java Format for JDK17 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2572";>#2572)](https://github-redirect.dependabot.com/mockito/mockito/pull/2572";>mockito/mockito#2572)
   Clean up JUnit3 references [(https://github-redirect.dependabot.com/mockito/mockito/issues/2570";>#2570)](https://github-redirect.dependabot.com/mockito/mockito/pull/2570";>mockito/mockito#2570)
   Bump com.diffplug.spotless from 6.2.2 to 6.3.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2567";>#2567)](https://github-redirect.dependabot.com/mockito/mockito/pull/2567";>mockito/mockito#2567)
   Bump google-java-format from 1.13.0 to 1.14.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2565";>#2565)](https://github-redirect.dependabot.com/mockito/mockito/pull/2565";>mockito/mockito#2565)
   Bump versions.bytebuddy from 1.12.7 to 1.12.8 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2564";>#2564)](https://github-redirect.dependabot.com/mockito/mockito/pull/2564";>mockito/mockito#2564)
   Bump com.diffplug.spotless from 6.2.1 to 6.2.2 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2562";>#2562)](https://github-redirect.dependabot.com/mockito/mockito/pull/2562";>mockito/mockito#2562)
   Bump com.github.ben-manes.versions from 0.41.0 to 0.42.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2559";>#2559)](https://github-redirect.dependabot.com/mockito/mockito/pull/2559";>mockito/mockito#2559)
   Bump com.diffplug.spotless from 6.2.0 to 6.2.1 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2556";>#2556)](https://github-redirect.dependabot.com/mockito/mockito/pull/2556";>mockito/mockito#2556)
   Fixes https://github-redirect.dependabot.com/mockito/mockito/issues/2548";>#2548
 : Makes InOrder able to verify static methods [(https://github-redirect.dependabot.com/mockito/mockito/issues/2549";>#2549)](https://github-redirect.dependabot.com/mockito/mockito/pull/2549";>mockito/mockito#2549)
   [PR open] Add feature to verify static methods calls in order [(https://github-redirect.dependabot.com/mockito/mockito/issues/2548";>#2548)](https://github-redirect.dependabot.com/mockito/mockito/issues/2548";>mockito/mockito#2548)
   Fixes https://github-redirect.dependabot.com/mockito/mockito/issues/2201";>#2201
 : Fixed checking of declared exceptions. [(https://github-redirect.dependabot.com/mockito/mockito/issues/2547";>#2547)](https://github-redirect.dependabot.com/mockito/mockito/pull/2547";>mockito/mockito#2547)
   Calling getExceptionTypes() on concrete object that is used as interface 
doesn't return exception types from interface [(https://github-redirect.dependabot.com/mockito/mockito/issues/2201";>#2201)](https://github-redirect.dependabot.com/mockito/mockito/issues/2201";>mockito/mockito#2201)
   
   v4.3.1
   Changelog generated 
by https://github.com/shipkit/shipkit-changelog";>Shipkit Changelog 
Gradle Plugin
   4.3.1
   
   2022-01-25 - https://github.com/mockito/mockito/compare/v4.3.0...v4.3.1";>1 
commit(s) by Stefano Cordio
   Add mockito-core

[GitHub] [maven-surefire] dantran commented on pull request #485: [SUREFIRE-2036] Fix JUnit 5 with configured provider



dantran commented on pull request #485:
URL: https://github.com/apache/maven-surefire/pull/485#issuecomment-1064739628


   @Tibor17  once this is merged, could you push a snapshot to 
repository.apache.org?   I would like to test it with our build early. Thanks


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-resolver] caiwei-ebay commented on a change in pull request #158: MRESOLVER-247: Introduce skipper to avoid unnecessary dependency reso…



caiwei-ebay commented on a change in pull request #158:
URL: https://github.com/apache/maven-resolver/pull/158#discussion_r824343285



##
File path: 
maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/collect/DependencyResolutionSkipperTest.java
##
@@ -0,0 +1,214 @@
+package org.eclipse.aether.internal.impl.collect;
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import org.eclipse.aether.RepositoryException;
+import org.eclipse.aether.artifact.DefaultArtifact;
+import org.eclipse.aether.graph.DefaultDependencyNode;
+import org.eclipse.aether.graph.Dependency;
+import org.eclipse.aether.graph.DependencyNode;
+import org.eclipse.aether.internal.test.util.TestVersion;
+import org.eclipse.aether.internal.test.util.TestVersionConstraint;
+import org.junit.Test;
+
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.List;
+import java.util.Map;
+import java.util.stream.Collectors;
+
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.assertFalse;
+import static org.junit.Assert.assertTrue;
+
+
+public class DependencyResolutionSkipperTest
+{
+private static DependencyNode makeDependencyNode( String groupId, String 
artifactId, String version )
+{
+return makeDependencyNode( groupId, artifactId, version, "compile" );
+}
+
+private static List mutableList( DependencyNode... nodes )
+{
+return new ArrayList<>( Arrays.asList( nodes ) );
+}
+
+private static DependencyNode makeDependencyNode( String groupId, String 
artifactId, String version, String scope )
+{
+DefaultDependencyNode node = new DefaultDependencyNode(
+new Dependency( new DefaultArtifact( groupId + ':' + 
artifactId + ':' + version ), scope )
+);
+node.setVersion( new TestVersion( version ) );
+node.setVersionConstraint( new TestVersionConstraint( 
node.getVersion() ) );
+return node;
+}
+
+@Test
+public void testSkipVersionConflict() throws RepositoryException
+{
+// A -> B -> C 3.0 -> D   => C3.0 SHOULD BE SKIPPED
+// | -> E -> F -> G
+// | -> C 2.0 -> H  => C2.0 is the winner
+DependencyNode aNode = makeDependencyNode( "some-group", "A", "1.0" );
+DependencyNode bNode = makeDependencyNode( "some-group", "B", "1.0" );
+DependencyNode c3Node = makeDependencyNode( "some-group", "C", "3.0" );
+DependencyNode dNode = makeDependencyNode( "some-group", "D", "1.0" );
+DependencyNode eNode = makeDependencyNode( "some-group", "E", "1.0" );
+DependencyNode fNode = makeDependencyNode( "some-group", "F", "1.0" );
+DependencyNode c2Node = makeDependencyNode( "some-group", "C", "2.0" );
+DependencyNode gNode = makeDependencyNode( "some-group", "G", "1.0" );
+DependencyNode hNode = makeDependencyNode( "some-group", "H", "1.0" );
+
+aNode.setChildren( mutableList( bNode, eNode, c2Node ) );
+bNode.setChildren( mutableList( c3Node ) );
+c3Node.setChildren( mutableList( dNode ) );
+eNode.setChildren( mutableList( fNode ) );
+fNode.setChildren( mutableList( gNode ) );
+c2Node.setChildren( mutableList( hNode ) );
+
+//follow the BFS resolve sequence
+DependencyResolutionSkipper skipper = new 
DependencyResolutionSkipper();
+assertFalse( skipper.skipResolution( aNode, new ArrayList<>() ) );
+skipper.cache( aNode, new ArrayList<>() );
+assertFalse( skipper.skipResolution( bNode, mutableList( aNode ) ) );
+skipper.cache( bNode, mutableList( aNode ) );
+assertFalse( skipper.skipResolution( eNode, mutableList( aNode ) ) );
+skipper.cache( eNode, mutableList( aNode ) );
+assertFalse( skipper.skipResolution( c2Node, mutableList( aNode ) ) );
+skipper.cache( c2Node, mutableList( aNode ) );
+assertTrue( skipper.skipResolution( c3Node, mutableList( aNode, bNode 
) ) );//version conflict
+assertFalse( skipper.skipResolution( fNode, mutableList( aNode, eNode 
) ) );
+skipper.cache( fNode, mutableList( aNode, eNode ) );
+assertFalse( skipper.skipResolution( gNode, muta

[GitHub] [maven-resolver] caiwei-ebay edited a comment on pull request #158: MRESOLVER-247: Introduce skipper to avoid unnecessary dependency reso…



caiwei-ebay edited a comment on pull request #158:
URL: https://github.com/apache/maven-resolver/pull/158#issuecomment-1064718770


   > There is a regression. Have a look at: 
[mng-5669.zip](https://github.com/apache/maven-resolver/files/8226394/mng-5669.zip)
 Please diff the sorted logfiles and you will see that some dependencies have 
disappeared from the listing.
   
   Actually this is expected behavior. Skipper would simply skip resolving the 
conflict losers which will make maven read/parse less poms. 
   
   Regarding the source poms as below, they are actually read only once. This 
means function in MNG-5669 does not break.
   How can I fix the IT? I did not find the code and unable to open the IT CI 
job.
   ```
   {org.apache.maven.model.io.inputSource=null null, 
org.apache.maven.model.io.isStrict=true, 
org.apache.maven.model.building.source=/var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-5669-read-poms-once/pom.xml}
   {org.apache.maven.model.io.inputSource=null null, 
org.apache.maven.model.io.isStrict=true, 
org.apache.maven.model.building.source=/var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-5669-read-poms-once/module1/pom.xml}
   {org.apache.maven.model.io.inputSource=null null, 
org.apache.maven.model.io.isStrict=true, 
org.apache.maven.model.building.source=/var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-5669-read-poms-once/module2/pom.xml}
   {org.apache.maven.model.io.inputSource=null null, 
org.apache.maven.model.io.isStrict=true, 
org.apache.maven.model.building.source=/var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-5669-read-poms-once/module3/pom.xml}
   ```


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-resolver] caiwei-ebay commented on pull request #158: MRESOLVER-247: Introduce skipper to avoid unnecessary dependency reso…



caiwei-ebay commented on pull request #158:
URL: https://github.com/apache/maven-resolver/pull/158#issuecomment-1064718770


   > There is a regression. Have a look at: 
[mng-5669.zip](https://github.com/apache/maven-resolver/files/8226394/mng-5669.zip)
 Please diff the sorted logfiles and you will see that some dependencies have 
disappeared from the listing.
   
   Actually this is expected behavior. Skipper would simply skip resolving the 
conflict losers which will make maven read/parse less poms. 
   
   Regarding the source poms, they are actually read only once. This means 
function in MNG-5669 does not break.
   How can I fix the IT? I did not find the code and unable to open the IT CI 
job.
   ```
   {org.apache.maven.model.io.inputSource=null null, 
org.apache.maven.model.io.isStrict=true, 
org.apache.maven.model.building.source=/var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-5669-read-poms-once/pom.xml}
   {org.apache.maven.model.io.inputSource=null null, 
org.apache.maven.model.io.isStrict=true, 
org.apache.maven.model.building.source=/var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-5669-read-poms-once/module1/pom.xml}
   {org.apache.maven.model.io.inputSource=null null, 
org.apache.maven.model.io.isStrict=true, 
org.apache.maven.model.building.source=/var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-5669-read-poms-once/module2/pom.xml}
   {org.apache.maven.model.io.inputSource=null null, 
org.apache.maven.model.io.isStrict=true, 
org.apache.maven.model.building.source=/var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-5669-read-poms-once/module3/pom.xml}
   ```


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-resolver] caiwei-ebay commented on a change in pull request #158: MRESOLVER-247: Introduce skipper to avoid unnecessary dependency reso…



caiwei-ebay commented on a change in pull request #158:
URL: https://github.com/apache/maven-resolver/pull/158#discussion_r824343285



##
File path: 
maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/collect/DependencyResolutionSkipperTest.java
##
@@ -0,0 +1,214 @@
+package org.eclipse.aether.internal.impl.collect;
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import org.eclipse.aether.RepositoryException;
+import org.eclipse.aether.artifact.DefaultArtifact;
+import org.eclipse.aether.graph.DefaultDependencyNode;
+import org.eclipse.aether.graph.Dependency;
+import org.eclipse.aether.graph.DependencyNode;
+import org.eclipse.aether.internal.test.util.TestVersion;
+import org.eclipse.aether.internal.test.util.TestVersionConstraint;
+import org.junit.Test;
+
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.List;
+import java.util.Map;
+import java.util.stream.Collectors;
+
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.assertFalse;
+import static org.junit.Assert.assertTrue;
+
+
+public class DependencyResolutionSkipperTest
+{
+private static DependencyNode makeDependencyNode( String groupId, String 
artifactId, String version )
+{
+return makeDependencyNode( groupId, artifactId, version, "compile" );
+}
+
+private static List mutableList( DependencyNode... nodes )
+{
+return new ArrayList<>( Arrays.asList( nodes ) );
+}
+
+private static DependencyNode makeDependencyNode( String groupId, String 
artifactId, String version, String scope )
+{
+DefaultDependencyNode node = new DefaultDependencyNode(
+new Dependency( new DefaultArtifact( groupId + ':' + 
artifactId + ':' + version ), scope )
+);
+node.setVersion( new TestVersion( version ) );
+node.setVersionConstraint( new TestVersionConstraint( 
node.getVersion() ) );
+return node;
+}
+
+@Test
+public void testSkipVersionConflict() throws RepositoryException
+{
+// A -> B -> C 3.0 -> D   => C3.0 SHOULD BE SKIPPED
+// | -> E -> F -> G
+// | -> C 2.0 -> H  => C2.0 is the winner
+DependencyNode aNode = makeDependencyNode( "some-group", "A", "1.0" );
+DependencyNode bNode = makeDependencyNode( "some-group", "B", "1.0" );
+DependencyNode c3Node = makeDependencyNode( "some-group", "C", "3.0" );
+DependencyNode dNode = makeDependencyNode( "some-group", "D", "1.0" );
+DependencyNode eNode = makeDependencyNode( "some-group", "E", "1.0" );
+DependencyNode fNode = makeDependencyNode( "some-group", "F", "1.0" );
+DependencyNode c2Node = makeDependencyNode( "some-group", "C", "2.0" );
+DependencyNode gNode = makeDependencyNode( "some-group", "G", "1.0" );
+DependencyNode hNode = makeDependencyNode( "some-group", "H", "1.0" );
+
+aNode.setChildren( mutableList( bNode, eNode, c2Node ) );
+bNode.setChildren( mutableList( c3Node ) );
+c3Node.setChildren( mutableList( dNode ) );
+eNode.setChildren( mutableList( fNode ) );
+fNode.setChildren( mutableList( gNode ) );
+c2Node.setChildren( mutableList( hNode ) );
+
+//follow the BFS resolve sequence
+DependencyResolutionSkipper skipper = new 
DependencyResolutionSkipper();
+assertFalse( skipper.skipResolution( aNode, new ArrayList<>() ) );
+skipper.cache( aNode, new ArrayList<>() );
+assertFalse( skipper.skipResolution( bNode, mutableList( aNode ) ) );
+skipper.cache( bNode, mutableList( aNode ) );
+assertFalse( skipper.skipResolution( eNode, mutableList( aNode ) ) );
+skipper.cache( eNode, mutableList( aNode ) );
+assertFalse( skipper.skipResolution( c2Node, mutableList( aNode ) ) );
+skipper.cache( c2Node, mutableList( aNode ) );
+assertTrue( skipper.skipResolution( c3Node, mutableList( aNode, bNode 
) ) );//version conflict
+assertFalse( skipper.skipResolution( fNode, mutableList( aNode, eNode 
) ) );
+skipper.cache( fNode, mutableList( aNode, eNode ) );
+assertFalse( skipper.skipResolution( gNode, muta

[GitHub] [maven-compiler-plugin] olamy merged pull request #100: Bump mockito-core from 4.3.1 to 4.4.0



olamy merged pull request #100:
URL: https://github.com/apache/maven-compiler-plugin/pull/100


   


-- 
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] olamy commented on pull request #478: [SUREFIRE-1426] Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true



olamy commented on pull request #478:
URL: https://github.com/apache/maven-surefire/pull/478#issuecomment-1064657277


   > @Tibor17 I hope I answered all your concerns and we can now merge this?
   
   @Tibor17  ping


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-surefire] Tibor17 commented on pull request #485: [SUREFIRE-2036] Fix JUnit 5 with configured provider



Tibor17 commented on pull request #485:
URL: https://github.com/apache/maven-surefire/pull/485#issuecomment-1064651932


   @roxspring 
   LGTM. It looks complete, right?


-- 
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] (SUREFIRE-2036) Regression: 3.0.0-M5 fails with configured JUnit 5 provider

2022-03-10 Thread Tibor Digana (Jira)



 [ 
https://issues.apache.org/jira/browse/SUREFIRE-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana updated SUREFIRE-2036:
---
Fix Version/s: 3.0.0-M6

> Regression: 3.0.0-M5 fails with configured JUnit 5 provider
> ---
>
> Key: SUREFIRE-2036
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2036
> Project: Maven Surefire
>  Issue Type: Bug
>Reporter: Robert James Oxspring
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> SUREFIRE-2033 breaks the automatic configuration of the JUnit 5 provider when 
> {{junit-platform-runner}} happens to be in the classpath, but additionally 
> manual override of this misconfiguration is broken too and results in a 
> {{{}NullPointerException{}}}.
> Specifically, using [https://github.com/apache/maven-surefire/pull/485]:
> {code:java}
> % mvn test -f surefire-its/src/test/resources/surefire-2036 
> -Dsurefire.version=3.0.0-M5 -X
> ...
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time:  1.022 s
> [INFO] Finished at: 2022-03-09T22:18:36Z
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (default-test) 
> on project surefire-2036: Execution default-test of goal 
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed.: 
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test 
> (default-test) on project surefire-2036: Execution default-test of goal 
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed.
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:215)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:156)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:148)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:81)
>     at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  (SingleThreadedBuilder.java:56)
>     at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:128)
>     at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
>     at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
>     at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
>     at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
>     at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
>     at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
>     at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>     at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
>     at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke (Method.java:566)
>     at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
>     at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
>     at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
>     at org.codehaus.plexus.classworlds.launcher.Launcher.main 
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
> default-test of goal 
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed.
>     at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:148)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:210)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:156)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:148)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:81)
>     at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  (SingleThreadedBuilder.java:56)
>     at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:128)
>     at org.apache.maven.DefaultMaven.doExecute (

[jira] [Updated] (JXR-166) Two versions of velocity engines on plugin classpath

2022-03-10 Thread Sylwester Lachiewicz (Jira)



 [ 
https://issues.apache.org/jira/browse/JXR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sylwester Lachiewicz updated JXR-166:
-
Affects Version/s: 3.2.0

> Two versions of velocity engines on plugin classpath
> 
>
> Key: JXR-166
> URL: https://issues.apache.org/jira/browse/JXR-166
> Project: Maven JXR
>  Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Slawomir Jaranowski
>Priority: Minor
>
> Velocity engine change *{{artifactId}}* in updates 1.7.x to 2.0.x
> https://velocity.apache.org/engine/2.2/upgrading.html#upgrading-from-velocity-17-to-velocity-20
> Now we have both.
> Dependency tree:
> {code}
> org.apache.maven.plugins:maven-jxr-plugin:maven-plugin:3.2.0-SNAPSHOT
> +- org.apache.maven:maven-jxr:jar:3.2.0-SNAPSHOT:compile
> |  +- org.apache.velocity:velocity-engine-core:jar:2.3:compile
> +- org.apache.maven.reporting:maven-reporting-impl:jar:3.1.0:compile
> |  \- org.apache.maven.doxia:doxia-site-renderer:jar:1.11.1:compile
> | +- org.codehaus.plexus:plexus-velocity:jar:1.2:compile
> | +- org.apache.velocity:velocity:jar:1.7:compile
> | +- org.apache.velocity:velocity-tools:jar:2.0:compile
> {code}
>  
> I don't see any errors so far ... but should be fixed.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (JXR-165) Upgrade Maven Reporting to 3.1.0



 [ 
https://issues.apache.org/jira/browse/JXR-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Slawomir Jaranowski reassigned JXR-165:
---

Assignee: Slawomir Jaranowski

> Upgrade Maven Reporting to 3.1.0
> 
>
> Key: JXR-165
> URL: https://issues.apache.org/jira/browse/JXR-165
> Project: Maven JXR
>  Issue Type: Dependency upgrade
>  Components: maven2 jxr plugin
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.2.0
>
>




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[GitHub] [maven-verifier] slawekjaranowski commented on pull request #9: [MSHARED-1043] Deprecate methods leveraging JUnit4 assertions



slawekjaranowski commented on pull request #9:
URL: https://github.com/apache/maven-verifier/pull/9#issuecomment-1064592627


   It is standard way, first deprecated method with documentation how should be 
replace - and we do this step.
   
   Next we release major version with removed methods in some time.
   
   


-- 
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] (JXR-157) Upgrade Velocity templating engine



[ 
https://issues.apache.org/jira/browse/JXR-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504638#comment-17504638
 ] 

Slawomir Jaranowski commented on JXR-157:
-

ok, now we have two version of velocity  JXR-166 on classpath

> Upgrade Velocity templating engine
> --
>
> Key: JXR-157
> URL: https://issues.apache.org/jira/browse/JXR-157
> Project: Maven JXR
>  Issue Type: Dependency upgrade
>Reporter: Sylwester Lachiewicz
>Assignee: Karl Heinz Marbaise
>Priority: Minor
>  Labels: Java8, up-for-grabs
> Fix For: 3.2.0
>
>
> Upgrade velocity templating engine to 2.2 
> [https://velocity.apache.org/engine/2.2/upgrading.html]
>  
> Requires Java 8



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (JXR-166) Two versions of velocity engines on plugin classpath

Slawomir Jaranowski created JXR-166:
---

 Summary: Two versions of velocity engines on plugin classpath
 Key: JXR-166
 URL: https://issues.apache.org/jira/browse/JXR-166
 Project: Maven JXR
  Issue Type: Bug
Reporter: Slawomir Jaranowski


Velocity engine change *{{artifactId}}* in updates 1.7.x to 2.0.x

https://velocity.apache.org/engine/2.2/upgrading.html#upgrading-from-velocity-17-to-velocity-20

Now we have both.

Dependency tree:

{code}
org.apache.maven.plugins:maven-jxr-plugin:maven-plugin:3.2.0-SNAPSHOT

+- org.apache.maven:maven-jxr:jar:3.2.0-SNAPSHOT:compile
|  +- org.apache.velocity:velocity-engine-core:jar:2.3:compile

+- org.apache.maven.reporting:maven-reporting-impl:jar:3.1.0:compile

|  \- org.apache.maven.doxia:doxia-site-renderer:jar:1.11.1:compile
| +- org.codehaus.plexus:plexus-velocity:jar:1.2:compile
| +- org.apache.velocity:velocity:jar:1.7:compile
| +- org.apache.velocity:velocity-tools:jar:2.0:compile

{code}
 
I don't see any errors so far ... but should be fixed.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (JXR-157) Upgrade Velocity templating engine

2022-03-10 Thread Sylwester Lachiewicz (Jira)



[ 
https://issues.apache.org/jira/browse/JXR-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504634#comment-17504634
 ] 

Sylwester Lachiewicz commented on JXR-157:
--

Yes, next step is to fix dixia-sitetools.

 

> Upgrade Velocity templating engine
> --
>
> Key: JXR-157
> URL: https://issues.apache.org/jira/browse/JXR-157
> Project: Maven JXR
>  Issue Type: Dependency upgrade
>Reporter: Sylwester Lachiewicz
>Assignee: Karl Heinz Marbaise
>Priority: Minor
>  Labels: Java8, up-for-grabs
> Fix For: 3.2.0
>
>
> Upgrade velocity templating engine to 2.2 
> [https://velocity.apache.org/engine/2.2/upgrading.html]
>  
> Requires Java 8



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (JXR-165) Upgrade Maven Reporting to 3.1.0

Slawomir Jaranowski created JXR-165:
---

 Summary: Upgrade Maven Reporting to 3.1.0
 Key: JXR-165
 URL: https://issues.apache.org/jira/browse/JXR-165
 Project: Maven JXR
  Issue Type: Dependency upgrade
  Components: maven2 jxr plugin
Reporter: Slawomir Jaranowski
 Fix For: 3.2.0






--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (JXR-157) Upgrade Velocity templating engine



[ 
https://issues.apache.org/jira/browse/JXR-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504623#comment-17504623
 ] 

Slawomir Jaranowski commented on JXR-157:
-

[~slachiewicz] [~khmarbaise] 

What benefit we have  now in log we will have many lines like ...
{code}
[main] WARN org.apache.velocity.deprecation - configuration key 
'velocimacro.library' has been deprecated in favor of 'velocimacro.library.path'
[main] WARN org.apache.velocity.deprecation - configuration key 
'velocimacro.permissions.allow.inline.to.replace.global' has been deprecated in 
favor of 'velocimacro.inline.replace_global'
[main] WARN org.apache.velocity.deprecation - configuration key 
'eventhandler.include.class' has been deprecated in favor of 
'event_handler.include.class'
{code}
 

> Upgrade Velocity templating engine
> --
>
> Key: JXR-157
> URL: https://issues.apache.org/jira/browse/JXR-157
> Project: Maven JXR
>  Issue Type: Dependency upgrade
>Reporter: Sylwester Lachiewicz
>Assignee: Karl Heinz Marbaise
>Priority: Minor
>  Labels: Java8, up-for-grabs
> Fix For: 3.2.0
>
>
> Upgrade velocity templating engine to 2.2 
> [https://velocity.apache.org/engine/2.2/upgrading.html]
>  
> Requires Java 8



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[GitHub] [maven] gnodet commented on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build



gnodet commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064530792


   > Just another observation, it seems `MojosExecutionStrategy` was jsut 
intorduced in maven `3.9.x` so how could it be a regression from `3.8.x`?
   
   Because it has been developed months ago on 3.8.x, but we decided to only 
merge into 3.9.x which has just been created a few days ago.  And the behavior 
was broken by 
https://github.com/apache/maven/commit/e327be3d85918a23a5ba48d752143a6dbf8b83f7 
which has been introduced in 3.8.x branch from which 3.9.x is derived.  
   
   > Just one thing I'm curious about: Why is the mavencache not used as a 
core-extension? I would suspect that this will give much more powerful and 
stable integration than just integrate it on the project level.
   
   The goal is to support both. I've added integration tests for both core and 
build extension for maven 3.9.x and 4.0.x.  You seem to indicate you'd rather 
use a core extension, but other think defining extensions in the pom is 
preferable (see 
https://github.com/apache/maven/pull/616#issuecomment-976624269).
   
   I'll answer the other points tomorrow after more investigation.


-- 
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-jxr] dependabot[bot] commented on pull request #44: Bump wagon-provider-api from 2.8 to 3.5.1



dependabot[bot] commented on pull request #44:
URL: https://github.com/apache/maven-jxr/pull/44#issuecomment-1064524263


   OK, I won't notify you again about this release, but will get in touch when 
a new version is available. If you'd rather skip all updates until the next 
major or minor version, let me know by commenting `@dependabot ignore this 
major version` or `@dependabot ignore this minor version`. You can also ignore 
all major, minor, or patch releases for a dependency by adding an [`ignore` 
condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore)
 with the desired `update_types` to your config file.
   
   If you change your mind, just re-open this PR and I'll resolve any conflicts 
on it.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-jxr] slawekjaranowski closed pull request #44: Bump wagon-provider-api from 2.8 to 3.5.1



slawekjaranowski closed pull request #44:
URL: https://github.com/apache/maven-jxr/pull/44


   


-- 
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] (MPLUGIN-394) Report-Mojo doesn't respect input encoding

2022-03-10 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MPLUGIN-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504579#comment-17504579
 ] 

ASF GitHub Bot commented on MPLUGIN-394:


michael-o commented on a change in pull request #73:
URL: https://github.com/apache/maven-plugin-tools/pull/73#discussion_r824149087



##
File path: 
maven-plugin-plugin/src/it/mplugin-394_report-encoding/invoker.properties
##
@@ -0,0 +1,18 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+# 
+#   http://www.apache.org/licenses/LICENSE-2.0
+# 
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+
+invoker.goals = -Dfile.encoding=CP1252 plugin:report

Review comment:
   Not really, since there is no portable way. What you are doing is you 
are passing a user property, not a system property. Unfortunately, Maven 
promotes those to system properties which is wrong and will likely go away with 
4 GA. If you can create a `jvm.config` and supply a README which describes this 
problem, I'd be happy with that, but in the `goals` it is logically wrong.




-- 
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


> Report-Mojo doesn't respect input encoding
> --
>
> Key: MPLUGIN-394
> URL: https://issues.apache.org/jira/browse/MPLUGIN-394
> Project: Maven Plugin Tools
>  Issue Type: Bug
>  Components: Plugin Plugin
>Affects Versions: 3.6.4
>Reporter: Sebastian Kühn
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.7.0
>
>
> {{plugin:report}} reads the Plugin-XML-File with with the platform encoding 
> instead of the specified input encoding. This results in an broken generated 
> XDoc and finally Site.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[GitHub] [maven-plugin-tools] michael-o commented on a change in pull request #73: [MPLUGIN-394] Respect input encoding



michael-o commented on a change in pull request #73:
URL: https://github.com/apache/maven-plugin-tools/pull/73#discussion_r824149087



##
File path: 
maven-plugin-plugin/src/it/mplugin-394_report-encoding/invoker.properties
##
@@ -0,0 +1,18 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+# 
+#   http://www.apache.org/licenses/LICENSE-2.0
+# 
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+
+invoker.goals = -Dfile.encoding=CP1252 plugin:report

Review comment:
   Not really, since there is no portable way. What you are doing is you 
are passing a user property, not a system property. Unfortunately, Maven 
promotes those to system properties which is wrong and will likely go away with 
4 GA. If you can create a `jvm.config` and supply a README which describes this 
problem, I'd be happy with that, but in the `goals` it is logically wrong.




-- 
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-verifier] elharo commented on pull request #9: [MSHARED-1043] Deprecate methods leveraging JUnit4 assertions



elharo commented on pull request #9:
URL: https://github.com/apache/maven-verifier/pull/9#issuecomment-1064485060


   It's more of a long term concern. Is anyone who's not the Maven project 
using this? If so, it's going to be really hard to remove the deprecated 
methods. 
   
   I agree that if we had a green field this approach is preferable. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-resolver] michael-o commented on pull request #158: MRESOLVER-247: Introduce skipper to avoid unnecessary dependency reso…



michael-o commented on pull request #158:
URL: https://github.com/apache/maven-resolver/pull/158#issuecomment-1064417880


   There is a regression. Have a look at: 
[mng-5669.zip](https://github.com/apache/maven-resolver/files/8226394/mng-5669.zip)
   Please diff the sorted logfiles and you will see that some dependencies have 
disappeared from the listing.
   


-- 
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-verifier] kwin commented on pull request #9: [MSHARED-1043] Deprecate methods leveraging JUnit4 assertions



kwin commented on pull request #9:
URL: https://github.com/apache/maven-verifier/pull/9#issuecomment-1064373755


   > I'm a little concerned that this is somewhat incompatible with existing 
usage. 
   
   This code should be fully backwards-compatible as no existing methods are 
removed/modified and only new ones are added. Some consumers can be seen at 
https://mvnrepository.com/artifact/org.apache.maven.shared/maven-verifier/usages.
 In any case a migration away from the deprecated methods should be pretty 
straightforward.


-- 
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-7429) The classloader containing build extensions should be used throughout the build



[ 
https://issues.apache.org/jira/browse/MNG-7429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504508#comment-17504508
 ] 

Michael Osipov commented on MNG-7429:
-

At least we can set the reactor CL for build extensions, no?

> The classloader containing build extensions should be used throughout the 
> build
> ---
>
> Key: MNG-7429
> URL: https://issues.apache.org/jira/browse/MNG-7429
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 4.0.0-alpha-1, 3.9.0, 3.8.5
>Reporter: Guillaume Nodet
>Priority: Major
>  Labels: Regression
>




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (MNG-7429) The classloader containing build extensions should be used throughout the build



 [ 
https://issues.apache.org/jira/browse/MNG-7429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MNG-7429:

Summary: The classloader containing build extensions should be used 
throughout the build  (was: The classloader containing build extension should 
be used throughout the build)

> The classloader containing build extensions should be used throughout the 
> build
> ---
>
> Key: MNG-7429
> URL: https://issues.apache.org/jira/browse/MNG-7429
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 4.0.0-alpha-1, 3.9.0, 3.8.5
>Reporter: Guillaume Nodet
>Priority: Major
>  Labels: Regression
>




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (MPOM-309) Upgrade TagList Maven Plugin from 2.4 to 3.0.0

Slawomir Jaranowski created MPOM-309:


 Summary: Upgrade TagList Maven Plugin from 2.4 to 3.0.0
 Key: MPOM-309
 URL: https://issues.apache.org/jira/browse/MPOM-309
 Project: Maven POMs
  Issue Type: Dependency upgrade
  Components: maven
Reporter: Slawomir Jaranowski
 Fix For: MAVEN-36


Release notes: 
[https://github.com/mojohaus/taglist-maven-plugin/releases/tag/taglist-maven-plugin-3.0.0]

 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (MPOM-308) Upgrade Maven PMD Plugin from 3.15.0 to 3.16.0

Slawomir Jaranowski created MPOM-308:


 Summary: Upgrade Maven PMD Plugin from 3.15.0 to 3.16.0
 Key: MPOM-308
 URL: https://issues.apache.org/jira/browse/MPOM-308
 Project: Maven POMs
  Issue Type: Dependency upgrade
  Components: maven
Reporter: Slawomir Jaranowski
 Fix For: MAVEN-36


Release notes https://github.com/apache/maven-parent/pull/57



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[GitHub] [maven] laeubi commented on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build



laeubi commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064296345


   Just another observation, it seems `MojosExecutionStrategy` was jsut 
intorduced in maven `3.9.x` so how could it be a regression from `3.8.x`?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven] laeubi commented on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build



laeubi commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064292516


   > Actually, the one that cause problems is the 
[BuildCacheMojosExecutionStrategy](https://github.com/apache/maven-build-cache-extension/blob/master/src/main/java/org/apache/maven/buildcache/BuildCacheMojosExecutionStrategy.java),
   
   Does this actually has to be session scoped at all? As the session is passed 
in is it really session scoped? Is the problem in the class itself or is the 
class not discovered? Because `MojoExecutor` is a singelton I don't think it 
actually is valid to assume it could use anything session/project scoped. If 
that is to be supported, I thin the `MojosExecutionStrategy` should not be 
injected but locked up for each project in `MojoExecutor.execute(MavenSession, 
List, ProjectIndex)`


-- 
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] laeubi commented on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build



laeubi commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064278668


   Just one thing I'm curious about: Why is the mavencache not used as a 
core-extension? I would suspect that this will give much more powerful and 
stable integration than just integrate it on the project level.


-- 
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] laeubi commented on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build



laeubi commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064275379


   > I've added a commit to revert 
[e327be3](https://github.com/apache/maven/commit/e327be3d85918a23a5ba48d752143a6dbf8b83f7)
 because it's useless.
   
   It is not useless but prevents a classloader leak as you have proven.
   
   > This restores the behavior from 3.8.4 when extensions are defined in the 
root pom
   
   From the code it is completely  irrelevant where you define your extension 
as long as you only define exactly **one** and this is simply a wrong 
assumption.
   
   > I'm willing to write an IT
   
   I don't think it is good to make such behavior part of the covered 
assumptions. Whether or not an extension is defined in the root or not should 
be completely opaque and all code that works with extensions seems to not 
assume that but that project defined defined extensions are project scoped 
(taken the usual merging rules into account).
   
   > but I can't write until we agree on the behavior...
   
   I think instead of reverting / restoring wrong behavior it would be much 
more profitable to find out whats the root cause for this. For example a stack 
trace where a CNF exception is triggered and maybe then we see that there is 
actually a `attatchToThread` is missing somewhere else (or we have other 
classloader leaks that are revealed by the fixed behavior).
   
   > Such use cases are clearly not well covered, especially inheritance 
between parent/child projects, ordering, concurrency, etc...
   
   Just from reading the code and debugging the maven internals, a 
session-scoped component was never meant to be provided by a project-scoped 
extension and that it worked was just a side-effect but I could be wrong. At 
laest the Maven-CLI has distinct Classlaodersetups on the cases where a project 
scoped extension has to be accessed.
   
   


-- 
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 edited a comment on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build

gnodet edited a comment on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064264508

I've added a commit to revert
https://github.com/apache/maven/commit/e327be3d85918a23a5ba48d752143a6dbf8b83f7
because it's useless.

This restores the behavior from 3.8.4 when extensions are defined in the
root pom and allows supporting the maven-build-cache-extension use case at
https://github.com/apache/maven-build-cache-extension/pull/8. This would break
builds that would define extensions in the parent and in a child and expect
them to be available later in the build. If we want to completely restore the
3.8.4 behavior, I can remove line
https://github.com/apache/maven/pull/690/files#diff-7698873d65eece16fdf2ba67293827f623994a3affa509b814eaf33abb4537daR84
so that the _last_ project with extensions wins.

I agree this is not perfect and we should better support defining build
extensions throughout the various projects in the reactor. Such use cases are
clearly not well covered, especially inheritance between parent/child projects,
ordering, concurrency, etc...

@michael-o @laeubi I'm willing to write an IT, but I can't write until we
agree on the behavior...

--
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 #690: [MNG-7429] The classloader containing build extension should be used throughout the build



gnodet commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064264508


   I've added a commit to revert 
https://github.com/apache/maven/commit/e327be3d85918a23a5ba48d752143a6dbf8b83f7 
because it's useless.
   
   This restores the  behavior from 3.8.4 when extensions are defined in the 
root pom and allows supporting the maven-build-cache-extension use case at 
https://github.com/apache/maven-build-cache-extension/pull/8.  This would break 
builds that would define extensions in the parent and in a child and expect 
them to be available later in the build.  If we want to completely restore the 
3.8.4 behavior, I can remove line 
https://github.com/apache/maven/pull/690/files#diff-7698873d65eece16fdf2ba67293827f623994a3affa509b814eaf33abb4537daR84
 so that the _last_ project with extensions wins.
   
   I agree this is not perfect and we should better support defining build 
extensions throughout the various projects in the reactor.  Such use cases are 
clearly not well covered, especially inheritance between parent/child projects, 
ordering, concurrency, etc...


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven] gnodet commented on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build



gnodet commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064222692


   > > It _was_ leaking : the current PR still reverts at the end of the build.
   > 
   > I don't think this is enough... as mentioned in the change, there is even 
this classloader used later on an further leaked as "the original" one as it is 
passed to another method call.
   > 
   > > I agree that specifying build extensions at various level of a reactor 
may lead o unpredictable results
   > 
   > I think this must be supported without issues, just think about a 
aggregator build pom that includes different other projects then some might 
define an extension an other don't. That will lead to failures in this build 
but not in the individual build. That's really a nightmare to debug and that 
why I'm a bit strict at those rules to not leaking classloaders. If at some 
places it is necessary that the project classloader is used it has to be set 
but reset instantly afterwards!
   > 
   > > Actually, the one that cause problems is the 
[BuildCacheMojosExecutionStrategy](https://github.com/apache/maven-build-cache-extension/blob/master/src/main/java/org/apache/maven/buildcache/BuildCacheMojosExecutionStrategy.java),
 and yes, it's session scoped because I'm aiming at integrating this extension 
in `mvnd` which reuses maven plexus realms and thus makes a much bigger 
difference between `@Singleton` and `@SessionScoped` components.
   > 
   > But it seems you are rely on undefined behavior here then and what you 
wantt to archive could actually only work with a core-extension.
   
   My assumption so far was that build extensions defined in the root pom 
should be available to all modules built within the reactor.  This implies that 
the classloader will not be destroyed before the session ends anyway and beans 
available if needed. This is broken, so I consider the previous commit a 
regression.
   The consequence is that the fact that the classloader is still the TCCL when 
building children is just a needed consequence of the above.  IIUC, the leak 
originally mentioned in MNG-7402 was that the classloader was *never* restored. 
 This PR actually restores the original TCCL after the build, so I think the 
original use case / problem is covered.
   
   That said, I'm all for improving the way extension works.  I've raised 
https://github.com/apache/maven/pull/616 a while ago, though this is about core 
extensions, but I think both have valid use cases.  But the use case you 
mention with aggregators for various projects is valid and would have to be 
covered, but I think it's broken now (especially with concurrent builds), so 
I'd rather address such new use cases in a different JIRA/PR.
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MNG-7429) The classloader containing build extension should be used throughout the build

2022-03-10 Thread Jira



[ 
https://issues.apache.org/jira/browse/MNG-7429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504363#comment-17504363
 ] 

Christoph Läubrich commented on MNG-7429:
-

I don't think there is one classlaoder for all build extensions but potentially 
one for each project.

> The classloader containing build extension should be used throughout the build
> --
>
> Key: MNG-7429
> URL: https://issues.apache.org/jira/browse/MNG-7429
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 4.0.0-alpha-1, 3.9.0, 3.8.5
>Reporter: Guillaume Nodet
>Priority: Major
>  Labels: Regression
>




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[GitHub] [maven] laeubi commented on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build

laeubi commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064186425

> It _was_ leaking : the current PR still reverts at the end of the build.

I don't think this is enough... as mentioned in the change, there is even
this classloader used later on an further leaked as "the original" one as it is
passed to another method call.

> I agree that specifying build extensions at various level of a reactor may
lead o unpredictable results

I think this must be supported without issues, just think about a aggregator
build pom that includes different other projects then some might define an
extension an other don't. That will lead to failures in this build but not in
the individual build. That's really a nightmare to debug and that why I'm a bit
strict at those rules to not leaking classloaders. If at some places it is
necessary that the project classloader is used it has to be set but reset
instantly afterwards!

> Actually, the one that cause problems is the
[BuildCacheMojosExecutionStrategy](https://github.com/apache/maven-build-cache-extension/blob/master/src/main/java/org/apache/maven/buildcache/BuildCacheMojosExecutionStrategy.java),
and yes, it's session scoped because I'm aiming at integrating this extension
in `mvnd` which reuses maven plexus realms and thus makes a much bigger
difference between `@Singleton` and `@SessionScoped` components.

But it seems you are rely on undefined behavior here then and what you wantt
to archive could actually only work with a core-extension.

--
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-7429) The classloader containing build extension should be used throughout the build

2022-03-10 Thread Guillaume Nodet (Jira)



 [ 
https://issues.apache.org/jira/browse/MNG-7429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet updated MNG-7429:
-
Labels: Regression  (was: )

> The classloader containing build extension should be used throughout the build
> --
>
> Key: MNG-7429
> URL: https://issues.apache.org/jira/browse/MNG-7429
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 4.0.0-alpha-1, 3.9.0, 3.8.5
>Reporter: Guillaume Nodet
>Priority: Major
>  Labels: Regression
>




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (MNG-7429) The classloader containing build extension should be used throughout the build

2022-03-10 Thread Guillaume Nodet (Jira)



 [ 
https://issues.apache.org/jira/browse/MNG-7429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet updated MNG-7429:
-
Summary: The classloader containing build extension should be used 
throughout the build  (was: The classloader containing build extension is not 
used throughout the build)

> The classloader containing build extension should be used throughout the build
> --
>
> Key: MNG-7429
> URL: https://issues.apache.org/jira/browse/MNG-7429
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 4.0.0-alpha-1, 3.9.0, 3.8.5
>Reporter: Guillaume Nodet
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (MNG-7429) The classloader containing build extension is not used throughout the build

2022-03-10 Thread Guillaume Nodet (Jira)

Guillaume Nodet created MNG-7429:


 Summary: The classloader containing build extension is not used 
throughout the build
 Key: MNG-7429
 URL: https://issues.apache.org/jira/browse/MNG-7429
 Project: Maven
  Issue Type: Bug
Affects Versions: 4.0.0-alpha-1, 3.9.0, 3.8.5
Reporter: Guillaume Nodet






--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[GitHub] [maven] gnodet commented on pull request #690: [MNG-7402] Make sure the top level project classloader is used throughout the build



gnodet commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064151253


   > @gnodet Does this apply to 3.8.x? I guess we need a new JIRA issue to 
clearly document this problem/regression.
   
   @michael-o It does apply to 3.8.x, and yes, I'll create a JIRA.
   
   > But this does actually shows that an project classlaoder is leaked. I 
don't see how reverting this makes the situation better (beside that 'it has 
worked before') as obviously here we have a gap where a **random** project 
classloader is used.
   
   It *was* leaking : the current PR still reverts at the end of the build.  
And yes, I agree that specifying build extensions at various level of a reactor 
may lead o unpredictable results.  However, 
* I think the current behavior (i.e. an extension defined at the top should 
be effective throughout the build) should be preserved
* while defining extensions inside the reactor is theoretically possible, I 
don't think any used that and I don't think we need to support those use cases
This leads me to think that reverting to the previous behavior is the way 
to do, while still avoiding the leak at the end of the build.
 
   > > Also, about the _last project_ point, I think in most cases, only the 
top level project has a specific classloader.
   > 
   > If it is not the last then "the last one that has a specific classloader", 
and working of such extensions then was jsut a side-effect and if thats true 
what you wrote why then all these "attach to thread" for each project? As far 
as i understand the "top level" is the pom actually executed and assume that 
that is the only valid one to have extensions seems a bit strange.
   
   Defining extensions not at the top level was broken, as you said, the last 
project defining extensions was used for the whole build.  So I assume that's 
actually not a use case and we don't need to fix it.  It would be easier to 
forbid them at the moment if we really want to fix the possible problem.
   
   
   
   > Do you refer to 
https://github.com/apache/maven-build-cache-extension/blob/master/src/main/java/org/apache/maven/buildcache/CacheLifecycleParticipant.java
 ? Why do you make this a session scoped `@Named` and not a plain 
`@Component(role = AbstractMavenLifecycleParticipant.class, hint = "cache")`? 
Thats how tycho works and maven sets the appropriate classlaoder when calling 
the methods.
   
   Actually, the one that cause problems is the 
[BuildCacheMojosExecutionStrategy](https://github.com/apache/maven-build-cache-extension/blob/master/src/main/java/org/apache/maven/buildcache/BuildCacheMojosExecutionStrategy.java),
 and yes, it's session scoped because I'm aiming at integrating this extension 
in `mvnd` which reuses maven plexus realms and thus makes a much bigger 
difference between `@Singleton` and `@SessionScoped` components.


-- 
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] laeubi commented on pull request #690: [MNG-7402] Make sure the top level project classloader is used throughout the build



laeubi commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064143527


   Do you refer to 
https://github.com/apache/maven-build-cache-extension/blob/master/src/main/java/org/apache/maven/buildcache/CacheLifecycleParticipant.java
 ? Why do you make this a session scoped `@Named` and not a plain 
`@Component(role = AbstractMavenLifecycleParticipant.class, hint = "cache")`? 
Thats how tycho works and maven sets the appropriate classlaoder when calling 
the methods.


-- 
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] laeubi commented on pull request #690: [MNG-7402] Make sure the top level project classloader is used throughout the build



laeubi commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064140324


   > The reason is that the extension defines a component with a session scope.
   
   By the way I already noticed that SessionScoped components are actually hard 
to implement, I used the `LegacySupport` as the only workaround to access the 
session in a maven-extension.


-- 
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] laeubi commented on pull request #690: [MNG-7402] Make sure the top level project classloader is used throughout the build



laeubi commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064134506


   > Also, about the _last project_ point, I think in most cases, only the top 
level project has a specific classloader.
   
   If it is not the last then "the last one that has a specific classloader", 
and working of such extensions then was jsut a side-effect and if thats true 
what you wrote why then all these "attach to thread" for each project? As far 
as i understand the "top level" is the pom actually executed and assume that 
that is the only valid one to have extensions seems a bit strange.


-- 
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] laeubi commented on pull request #690: [MNG-7402] Make sure the top level project classloader is used throughout the build



laeubi commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064130054


   But this does actually shows that an project classlaoder is leaked. I don't 
see how reverting this makes the situation better (beside that 'it has worked 
before') as obviously here we have a gap where a **random** project classloader 
is used.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven] michael-o edited a comment on pull request #690: [MNG-7402] Make sure the top level project classloader is used throughout the build



michael-o edited a comment on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064129782


   @gnodet Does this apply to 3.8.x? I guess we need a new JIRA issue to 
clearly document this problem/regression.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven] michael-o commented on pull request #690: [MNG-7402] Make sure the top level project classloader is used throughout the build



michael-o commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064129782


   @gnodet Does this apply to 3.8.x? I guess we need a new JIRA issue to 
clearly document this problem/regressin.


-- 
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 edited a comment on pull request #690: [MNG-7402] Make sure the top level project classloader is used throughout the build



gnodet edited a comment on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064126265


   > But why/how does it breaks them? As described in the PR this currently 
leaks the CCL of the _last_ project in the chain, and even if it makes 
extensions work somehow it is clearly broken.
   
   See https://github.com/apache/maven-build-cache-extension/pull/8 where the 
build extension test is broken on 3.9.x.  I bisected the problem to 
https://github.com/apache/maven/commit/e327be3d85918a23a5ba48d752143a6dbf8b83f7.
   
   The reason is that the extension defines a component with a session scope.  
This component is defined in the project's classloader (because it's a build 
extension and not a core extension).  This means that when the component is 
loaded, the projects classloader has to be used, else the component will not be 
seen by plexus.  The previous commit reverts the TCCL to the core maven one 
before actually building the project.  This PR aims at broadening the window 
where the project's classloader is used, and still revert it at the end.
   
   Also, about the _last project_ point, I think in most cases, only the top 
level project has a specific classloader.  The behavior before the previous 
commit was then that the top level project was used to set the TCCL, and the 
other projects, not having any specific classloader defined (if not defining 
any build extension), were simply ignored.


-- 
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 #690: [MNG-7402] Make sure the top level project classloader is used throughout the build



gnodet commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064126265


   > But why/how does it breaks them? As described in the PR this currently 
leaks the CCL of the _last_ project in the chain, and even if it makes 
extensions work somehow it is clearly broken.
   
   See https://github.com/apache/maven-build-cache-extension/pull/8 where the 
build extension test is broken on 3.9.x.  I bisected the problem to 
https://github.com/apache/maven/commit/e327be3d85918a23a5ba48d752143a6dbf8b83f7.
   
   The reason is that the extension defines a component with a session scope.  
This component is defined in the project's classloader (because it's a build 
extension and not a core extension).  This means that when the component is 
loaded, the projects classloader has to be used, else the component will not be 
seen by plexus.  The previous commit reverts the TCCL to the core maven one 
before actually building the project.  This PR aims at broadening the window 
where the project's classloader is used, and still revert it at the end.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Created] (MPOM-307) Upgrade Maven Dependency Plugin from 3.2.0 to 3.3.0

Slawomir Jaranowski created MPOM-307:


 Summary: Upgrade Maven Dependency Plugin from 3.2.0 to 3.3.0
 Key: MPOM-307
 URL: https://issues.apache.org/jira/browse/MPOM-307
 Project: Maven POMs
  Issue Type: Dependency upgrade
  Components: asf
Reporter: Slawomir Jaranowski
 Fix For: ASF-26


h1. Release Notes - Maven Dependency Plugin - Version 3.3.0

h2. Bug
* [MDEP-679] - mvn dependency:analyze detected wrong transitive dependency
* [MDEP-742] - dependency plugin does not work with JDK 16
* [MDEP-752] - skip dependency analyze in ear packaging
* [MDEP-753] - Non-test dependency reported as Non-test scoped test only 
dependency
* [MDEP-759] - 'Dependency not found' with 3.2.0 and Java-17 while analyzing
* [MDEP-761] - Tree plugin does not terminate with 3.2.0
* [MDEP-769] - Minor improvement - continue
* [MDEP-774] - analyze-only failed: PermittedSubclasses requires ASM9
* [MDEP-781] - Broken Link to "Introduction to Dependency Mechanism Page"
* [MDEP-783] - TreeMojo docs say scope doesn't work due to MSHARED-4
* [MDEP-786] - Sealed classes not supported

h2. New Feature
* [MDEP-787] - Allow ignoring non-test-scoped dependencies

h2. Improvement
* [MDEP-763] - Minor improvements
* [MDEP-768] - GitHub Action build improvement
* [MDEP-779] - dependency:analyze should list the classes that cause a used 
undeclared dependency
* [MDEP-789] - Improve documentation of analyze - Non-test scoped

h2. Task
* [MDEP-760] - Java 1.8 as minimum

h2. Dependency upgrade
* [MDEP-766] - Upgrade maven-invoker-plugin to version 3.2.2
* [MDEP-784] - Upgrade maven-dependency-analyzer to 1.12.0
* [MDEP-788] - Upgrade maven-reporting-impl to version 3.1.0
* [MDEP-795] - Update Jetty to 9.4.45.v20220203
* [MDEP-796] - Upgrade Maven Parent to 35
* [MDEP-797] - Update transitive dependency commons-beanutils to 1.9.4
* [MDEP-798] - Upgrade maven-dependency-tree from 3.0.1 to 3.1.0



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[GitHub] [maven] laeubi edited a comment on pull request #690: [MNG-7402] Make sure the top level project classloader is used throughout the build



laeubi edited a comment on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064122112


   But why/how does it breaks them? As described in the PR this currently leaks 
the CCL of the *last* project in the chain, and even if it makes extensions 
work somehow it is clearly broken so I think both are probably needed...


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven] laeubi commented on pull request #690: [MNG-7402] Make sure the top level project classloader is used throughout the build



laeubi commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064122112


   But why/how does it breaks them? As described in the PR this currently leaks 
the CCL of the *last* project in the chain, and even if it makes extensions 
work somehow it is clearly broken.


-- 
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 #690: [MNG-7402] Make sure the top level project classloader is used throughout the build



gnodet commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064120857


   > This looks like another issue that is only similar to the other fix, but 
why should anything be reverted?
   
   It's not another issue.  The 
https://github.com/apache/maven/commit/e327be3d85918a23a5ba48d752143a6dbf8b83f7 
commit actually breaks build extension.  This PR fixes the problem, but the 
older commit is meaningless once this one is applied, as the classloader is 
already reverted by this fix (which was the original problem iiuc).


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Created] (MPOM-306) Upgrade Maven Compiler Plugin from 3.10.0 to 3.10.1

Slawomir Jaranowski created MPOM-306:


 Summary: Upgrade Maven Compiler Plugin from 3.10.0 to 3.10.1
 Key: MPOM-306
 URL: https://issues.apache.org/jira/browse/MPOM-306
 Project: Maven POMs
  Issue Type: Dependency upgrade
  Components: asf
Reporter: Slawomir Jaranowski
 Fix For: ASF-26


h1. Release Notes - Maven Compiler Plugin - Version 3.10.1

h2. Bug
* [MCOMPILER-346] - workaround to jdk bug: assertionError inside javac when 
using javax.tools API
* [MCOMPILER-485] - Incorrect internal string format in generated 
package-info.class files on Windows

h2. New Feature
* [MCOMPILER-426] - dedicated option for enabling preview feature




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (MRELEASE-1080) Maven v3.8.4 exits with non-zero status from release:perform or :prepare even when successful



[ 
https://issues.apache.org/jira/browse/MRELEASE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504300#comment-17504300
 ] 

Michael Osipov commented on MRELEASE-1080:
--

Here is likely your answer: 
https://maven.apache.org/maven-release/maven-release-plugin/dependencies.html:
org.codehaus.plexus plexus-interactivity-api1.0-alpha-6

Override the dependency to 1.1 and try again. I guess I need to push M6 with a 
fix.

> Maven v3.8.4 exits with non-zero status from release:perform or :prepare even 
> when successful
> -
>
> Key: MRELEASE-1080
> URL: https://issues.apache.org/jira/browse/MRELEASE-1080
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: perform, prepare
>Affects Versions: 3.0.0-M5
> Environment: Windows 10, Git for Windows Bourne Again Shell, Maven 
> 3.8.4
>Reporter: Mirko Klemm
>Priority: Major
>  Labels: exit, shell
> Fix For: waiting-for-feedback
>
>
> When doing a "release:prepare" or "release:perform", the maven process always 
> exits with a shell exit status of 1, even when the goal has finished with a 
> "BUILD SUCCESS" message, where it actually should return 0.
> This doesn't seem to have been the case with 2.x versions of the plugin.
> This is an important bug since it messes up using maven and the release 
> plugin in shell scripts.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[GitHub] [maven] laeubi commented on pull request #690: [MNG-7402] Make sure the top level project classloader is used throughout the build



laeubi commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064116419


   This looks like another issue that is only similar to the other fix, but why 
should anything be reverted?


-- 
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 #690: [MNG-7402] Make sure the top level project classloader is used throughout the build



gnodet commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064115889


   > > > What is a build extension is declared in a submodule only?
   > > 
   > > 
   > > You mean "what if" ? That's my point, I don't think there are solid 
expectations wrt to the reactor hierarchy. What if it's defined in a child 
which itself has children ? etc
   > 
   > Yes, that was my question. Just a typo. So you don't expect any problems 
with that?
   
   I do expect problems, but I don't think it really matters because I don't 
think there's an actual use case for that.
   I'll push another commit to revert the previous fix at the same time, so 
that the behavior will be the same as before (broken or not).


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven] michael-o commented on pull request #690: [MNG-7402] Make sure the top level project classloader is used throughout the build



michael-o commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064111957


   > > What is a build extension is declared in a submodule only?
   > 
   > You mean "what if" ? That's my point, I don't think there are solid 
expectations wrt to the reactor hierarchy. What if it's defined in a child 
which itself has children ? etc
   
   Yes, that was my question. Just a typo. So you don't expect any problems 
with that?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-resolver] michael-o commented on pull request #158: MRESOLVER-247: Introduce skipper to avoid unnecessary dependency reso…



michael-o commented on pull request #158:
URL: https://github.com/apache/maven-resolver/pull/158#issuecomment-1064109525


   I will leave @ibabiankou at least a week to test and respond.


-- 
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] (MRELEASE-1080) Maven v3.8.4 exits with non-zero status from release:perform or :prepare even when successful



[ 
https://issues.apache.org/jira/browse/MRELEASE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504291#comment-17504291
 ] 

Mirko Klemm commented on MRELEASE-1080:
---

Oh yes, possibly. But versions before 3.0.0 of the plugin don't seem to behave 
like this. Do you have a hint what the latest version without closing 
System.out could be? We would downgrade to that then...

> Maven v3.8.4 exits with non-zero status from release:perform or :prepare even 
> when successful
> -
>
> Key: MRELEASE-1080
> URL: https://issues.apache.org/jira/browse/MRELEASE-1080
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: perform, prepare
>Affects Versions: 3.0.0-M5
> Environment: Windows 10, Git for Windows Bourne Again Shell, Maven 
> 3.8.4
>Reporter: Mirko Klemm
>Priority: Major
>  Labels: exit, shell
> Fix For: waiting-for-feedback
>
>
> When doing a "release:prepare" or "release:perform", the maven process always 
> exits with a shell exit status of 1, even when the goal has finished with a 
> "BUILD SUCCESS" message, where it actually should return 0.
> This doesn't seem to have been the case with 2.x versions of the plugin.
> This is an important bug since it messes up using maven and the release 
> plugin in shell scripts.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (MPOM-305) Set minimum enforced Maven version to 3.2.5

Slawomir Jaranowski created MPOM-305:


 Summary: Set minimum enforced Maven version to 3.2.5
 Key: MPOM-305
 URL: https://issues.apache.org/jira/browse/MPOM-305
 Project: Maven POMs
  Issue Type: Dependency upgrade
  Components: asf
Reporter: Slawomir Jaranowski
 Fix For: ASF-26


Used plugins required Maven 3.2.5

- maven-compiler-plugin from 3.9.0
- maven-plugin-plugin from 3.6.4



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[GitHub] [maven-resolver] michael-o commented on a change in pull request #158: MRESOLVER-247: Introduce skipper to avoid unnecessary dependency reso…



michael-o commented on a change in pull request #158:
URL: https://github.com/apache/maven-resolver/pull/158#discussion_r823761761



##
File path: 
maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/collect/DependencyResolutionSkipperTest.java
##
@@ -0,0 +1,214 @@
+package org.eclipse.aether.internal.impl.collect;
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import org.eclipse.aether.RepositoryException;
+import org.eclipse.aether.artifact.DefaultArtifact;
+import org.eclipse.aether.graph.DefaultDependencyNode;
+import org.eclipse.aether.graph.Dependency;
+import org.eclipse.aether.graph.DependencyNode;
+import org.eclipse.aether.internal.test.util.TestVersion;
+import org.eclipse.aether.internal.test.util.TestVersionConstraint;
+import org.junit.Test;
+
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.List;
+import java.util.Map;
+import java.util.stream.Collectors;
+
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.assertFalse;
+import static org.junit.Assert.assertTrue;
+
+
+public class DependencyResolutionSkipperTest
+{
+private static DependencyNode makeDependencyNode( String groupId, String 
artifactId, String version )
+{
+return makeDependencyNode( groupId, artifactId, version, "compile" );
+}
+
+private static List mutableList( DependencyNode... nodes )
+{
+return new ArrayList<>( Arrays.asList( nodes ) );
+}
+
+private static DependencyNode makeDependencyNode( String groupId, String 
artifactId, String version, String scope )
+{
+DefaultDependencyNode node = new DefaultDependencyNode(
+new Dependency( new DefaultArtifact( groupId + ':' + 
artifactId + ':' + version ), scope )
+);
+node.setVersion( new TestVersion( version ) );
+node.setVersionConstraint( new TestVersionConstraint( 
node.getVersion() ) );
+return node;
+}
+
+@Test
+public void testSkipVersionConflict() throws RepositoryException
+{
+// A -> B -> C 3.0 -> D   => C3.0 SHOULD BE SKIPPED
+// | -> E -> F -> G
+// | -> C 2.0 -> H  => C2.0 is the winner
+DependencyNode aNode = makeDependencyNode( "some-group", "A", "1.0" );
+DependencyNode bNode = makeDependencyNode( "some-group", "B", "1.0" );
+DependencyNode c3Node = makeDependencyNode( "some-group", "C", "3.0" );
+DependencyNode dNode = makeDependencyNode( "some-group", "D", "1.0" );
+DependencyNode eNode = makeDependencyNode( "some-group", "E", "1.0" );
+DependencyNode fNode = makeDependencyNode( "some-group", "F", "1.0" );
+DependencyNode c2Node = makeDependencyNode( "some-group", "C", "2.0" );
+DependencyNode gNode = makeDependencyNode( "some-group", "G", "1.0" );
+DependencyNode hNode = makeDependencyNode( "some-group", "H", "1.0" );
+
+aNode.setChildren( mutableList( bNode, eNode, c2Node ) );
+bNode.setChildren( mutableList( c3Node ) );
+c3Node.setChildren( mutableList( dNode ) );
+eNode.setChildren( mutableList( fNode ) );
+fNode.setChildren( mutableList( gNode ) );
+c2Node.setChildren( mutableList( hNode ) );
+
+//follow the BFS resolve sequence
+DependencyResolutionSkipper skipper = new 
DependencyResolutionSkipper();
+assertFalse( skipper.skipResolution( aNode, new ArrayList<>() ) );
+skipper.cache( aNode, new ArrayList<>() );
+assertFalse( skipper.skipResolution( bNode, mutableList( aNode ) ) );
+skipper.cache( bNode, mutableList( aNode ) );
+assertFalse( skipper.skipResolution( eNode, mutableList( aNode ) ) );
+skipper.cache( eNode, mutableList( aNode ) );
+assertFalse( skipper.skipResolution( c2Node, mutableList( aNode ) ) );
+skipper.cache( c2Node, mutableList( aNode ) );
+assertTrue( skipper.skipResolution( c3Node, mutableList( aNode, bNode 
) ) );//version conflict
+assertFalse( skipper.skipResolution( fNode, mutableList( aNode, eNode 
) ) );
+skipper.cache( fNode, mutableList( aNode, eNode ) );
+assertFalse( skipper.skipResolution( gNode, mutabl

[GitHub] [maven] gnodet edited a comment on pull request #690: [MNG-7402] Make sure the top level project classloader is used throughout the build



gnodet edited a comment on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064107249


   > What is a build extension is declared in a submodule only?
   
   You mean "what if" ?
   That's my point, I don't think there are solid expectations wrt to the 
reactor hierarchy.  What if it's defined in a child which itself has children ? 
etc


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven] gnodet commented on pull request #690: [MNG-7402] Make sure the top level project classloader is used throughout the build



gnodet commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064107249


   > What is a build extension is declared in a submodule only?
   
   You mean "what if" ?


-- 
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] (MRELEASE-1080) Maven v3.8.4 exits with non-zero status from release:perform or :prepare even when successful



[ 
https://issues.apache.org/jira/browse/MRELEASE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504288#comment-17504288
 ] 

Michael Osipov commented on MRELEASE-1080:
--

This reminds me of 
https://github.com/codehaus-plexus/plexus-interactivity/commit/58cbbe06afd5ad61b9481180e9228c6e7cea187c
 and 
https://github.com/codehaus-plexus/plexus-interactivity/commit/3c81b90cef4b2b9cf3d4188061ab9fe9addf34bc

> Maven v3.8.4 exits with non-zero status from release:perform or :prepare even 
> when successful
> -
>
> Key: MRELEASE-1080
> URL: https://issues.apache.org/jira/browse/MRELEASE-1080
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: perform, prepare
>Affects Versions: 3.0.0-M5
> Environment: Windows 10, Git for Windows Bourne Again Shell, Maven 
> 3.8.4
>Reporter: Mirko Klemm
>Priority: Major
>  Labels: exit, shell
> Fix For: waiting-for-feedback
>
>
> When doing a "release:prepare" or "release:perform", the maven process always 
> exits with a shell exit status of 1, even when the goal has finished with a 
> "BUILD SUCCESS" message, where it actually should return 0.
> This doesn't seem to have been the case with 2.x versions of the plugin.
> This is an important bug since it messes up using maven and the release 
> plugin in shell scripts.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] (MRELEASE-1080) Maven v3.8.4 exits with non-zero status from release:perform or :prepare even when successful



[ https://issues.apache.org/jira/browse/MRELEASE-1080 ]


Mirko Klemm deleted comment on MRELEASE-1080:
---

was (Author: JIRAUSER286414):
Investigated further: There seems to be an internal WARNING which also occurs 
only under GIT bash. During release tagging and "git commit" in the plugin, for 
every file untracked with git I get a warning:

{{[WARNING] Ignoring unrecognized line: ?? 
src/test/resources/Defaults_by_New_Default_Definition.csv}}

The release:prepare still ends with "BUILD SUCCESS".

This doesn't happen under CMD and PowerShell.

Maybe this is what leads to the non-zero exit status?

> Maven v3.8.4 exits with non-zero status from release:perform or :prepare even 
> when successful
> -
>
> Key: MRELEASE-1080
> URL: https://issues.apache.org/jira/browse/MRELEASE-1080
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: perform, prepare
>Affects Versions: 3.0.0-M5
> Environment: Windows 10, Git for Windows Bourne Again Shell, Maven 
> 3.8.4
>Reporter: Mirko Klemm
>Priority: Major
>  Labels: exit, shell
> Fix For: waiting-for-feedback
>
>
> When doing a "release:prepare" or "release:perform", the maven process always 
> exits with a shell exit status of 1, even when the goal has finished with a 
> "BUILD SUCCESS" message, where it actually should return 0.
> This doesn't seem to have been the case with 2.x versions of the plugin.
> This is an important bug since it messes up using maven and the release 
> plugin in shell scripts.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[GitHub] [maven] michael-o commented on pull request #690: [MNG-7402] Make sure the top level project classloader is used throughout the build



michael-o commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064095385


   What is a build extension is declared in a submodule only?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven] michael-o edited a comment on pull request #690: [MNG-7402] Make sure the top level project classloader is used throughout the build



michael-o edited a comment on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064075575


   This does not supersede e327be3d85918a23a5ba48d752143a6dbf8b83f7, but 
complements it?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Created] (MPOM-304) Upgrade Maven Project Info Reports Plugin from 3.1.2 to 3.2.2

Slawomir Jaranowski created MPOM-304:


 Summary: Upgrade Maven Project Info Reports Plugin from 3.1.2 to 
3.2.2
 Key: MPOM-304
 URL: https://issues.apache.org/jira/browse/MPOM-304
 Project: Maven POMs
  Issue Type: Dependency upgrade
  Components: asf
Reporter: Slawomir Jaranowski
 Fix For: ASF-26


h1. Release Notes - Maven Project Info Reports Plugin - Version 3.2.1

h2. Bug
* [MPIR-403] - Travis link should point to travis-ci.com instead of 
travis-ci.org
* [MPIR-404] - Warn and accept invalid mailing list links
* [MPIR-405] - Regression in Maven site rendering due to Doxia change to 
HTML5
* [MPIR-412] - Dependency report generates non-well-formed output if the 
POM of a depdendency cannot be parsed

h2. Improvement
* [MPIR-408] - Add some i18n properties for zh_CH

h2. Dependency upgrade
* [MPIR-409] - Upgrade Maven Site Plugin to 3.10.0
* [MPIR-410] - Upgrade Maven SCM to 1.12.2
* [MPIR-411] - Upgrade Doxia to 1.11.1 and Doxia Sitetools to 1.11.1

h1. Release Notes - Maven Project Info Reports Plugin - Version 3.2.2

h2. Bug
* [MPIR-413] - Plugin repositories defined in project are not used by 
plugin-management report

h2. Dependency upgrade
* [MPIR-414] - Upgrade Maven Reporting API/Impl to 3.1.0





--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (MRELEASE-1080) Maven v3.8.4 exits with non-zero status from release:perform or :prepare even when successful



[ 
https://issues.apache.org/jira/browse/MRELEASE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504285#comment-17504285
 ] 

Mirko Klemm commented on MRELEASE-1080:
---

Investigated further: There seems to be an internal WARNING which also occurs 
only under GIT bash. During release tagging and "git commit" in the plugin, for 
every file untracked with git I get a warning:

{{[WARNING] Ignoring unrecognized line: ?? 
src/test/resources/Defaults_by_New_Default_Definition.csv}}

The release:prepare still ends with "BUILD SUCCESS".

This doesn't happen under CMD and PowerShell.

Maybe this is what leads to the non-zero exit status?

> Maven v3.8.4 exits with non-zero status from release:perform or :prepare even 
> when successful
> -
>
> Key: MRELEASE-1080
> URL: https://issues.apache.org/jira/browse/MRELEASE-1080
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: perform, prepare
>Affects Versions: 3.0.0-M5
> Environment: Windows 10, Git for Windows Bourne Again Shell, Maven 
> 3.8.4
>Reporter: Mirko Klemm
>Priority: Major
>  Labels: exit, shell
> Fix For: waiting-for-feedback
>
>
> When doing a "release:prepare" or "release:perform", the maven process always 
> exits with a shell exit status of 1, even when the goal has finished with a 
> "BUILD SUCCESS" message, where it actually should return 0.
> This doesn't seem to have been the case with 2.x versions of the plugin.
> This is an important bug since it messes up using maven and the release 
> plugin in shell scripts.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (MRELEASE-1080) Maven v3.8.4 exits with non-zero status from release:perform or :prepare even when successful



[ 
https://issues.apache.org/jira/browse/MRELEASE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504281#comment-17504281
 ] 

Mirko Klemm commented on MRELEASE-1080:
---

Yes, just checked:
 * In Windows CMD, %errorlevel% is 0
 * In PowerShell, $LastExitCode is 0
 * In GIT Bash, $? is 1

So the error occurs only under GIT Bash

> Maven v3.8.4 exits with non-zero status from release:perform or :prepare even 
> when successful
> -
>
> Key: MRELEASE-1080
> URL: https://issues.apache.org/jira/browse/MRELEASE-1080
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: perform, prepare
>Affects Versions: 3.0.0-M5
> Environment: Windows 10, Git for Windows Bourne Again Shell, Maven 
> 3.8.4
>Reporter: Mirko Klemm
>Priority: Major
>  Labels: exit, shell
> Fix For: waiting-for-feedback
>
>
> When doing a "release:prepare" or "release:perform", the maven process always 
> exits with a shell exit status of 1, even when the goal has finished with a 
> "BUILD SUCCESS" message, where it actually should return 0.
> This doesn't seem to have been the case with 2.x versions of the plugin.
> This is an important bug since it messes up using maven and the release 
> plugin in shell scripts.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[GitHub] [maven] gnodet commented on pull request #690: [MNG-7402] Make sure the top level project classloader is used throughout the build



gnodet commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064078828


   > This does not supersede 
[e327be3](https://github.com/apache/maven/commit/e327be3d85918a23a5ba48d752143a6dbf8b83f7)
 but complements it?
   
   Yes, I actually don't think the first commit is really relevant or useful 
with the current fix.  I think in most cases, only the top level project has a 
classloader, which means the previous commit won't actually do anything and the 
classloader will remain the same.
   
   The problem is that I don’t think the behavior is defined for the “scope” of 
such extensions for reactor builds.  My assumption is that they are defined on 
the top level project and should be available for the whole execution, hence 
the fix that registers the top level project classloader… a bit earlier in the 
maven execution.
   
   So, I guess the answer should be yes !


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven] michael-o commented on pull request #690: [MNG-7402] Make sure the top level project classloader is used throughout the build



michael-o commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064076137


   @laeubi can you check also?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven] michael-o commented on pull request #690: [MNG-7402] Make sure the top level project classloader is used throughout the build



michael-o commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064075575


   This does not supersede e327be3d85918a23a5ba48d752143a6dbf8b83f7 but 
complements it?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MRELEASE-1080) Maven v3.8.4 exits with non-zero status from release:perform or :prepare even when successful



[ 
https://issues.apache.org/jira/browse/MRELEASE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504266#comment-17504266
 ] 

Michael Osipov commented on MRELEASE-1080:
--

Does it work with Windows Command Prompt or PowerShell?

> Maven v3.8.4 exits with non-zero status from release:perform or :prepare even 
> when successful
> -
>
> Key: MRELEASE-1080
> URL: https://issues.apache.org/jira/browse/MRELEASE-1080
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: perform, prepare
>Affects Versions: 3.0.0-M5
> Environment: Windows 10, Git for Windows Bourne Again Shell, Maven 
> 3.8.4
>Reporter: Mirko Klemm
>Priority: Major
>  Labels: exit, shell
> Fix For: waiting-for-feedback
>
>
> When doing a "release:prepare" or "release:perform", the maven process always 
> exits with a shell exit status of 1, even when the goal has finished with a 
> "BUILD SUCCESS" message, where it actually should return 0.
> This doesn't seem to have been the case with 2.x versions of the plugin.
> This is an important bug since it messes up using maven and the release 
> plugin in shell scripts.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[GitHub] [maven] gnodet opened a new pull request #690: [MNG-7402] Make sure the top level project classloader is used throughout the build



gnodet opened a new pull request #690:
URL: https://github.com/apache/maven/pull/690


   This fixes problems when using build extensions.


-- 
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] (MRELEASE-1080) Maven v3.8.4 exits with non-zero status from release:perform or :prepare even when successful



 [ 
https://issues.apache.org/jira/browse/MRELEASE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mirko Klemm updated MRELEASE-1080:
--
Environment: 
Windows 10, Git for Windows Bourne Again Shell, Maven 3.8.4


  was:Windows 10, Git for Windows Bourne Again Shell


> Maven v3.8.4 exits with non-zero status from release:perform or :prepare even 
> when successful
> -
>
> Key: MRELEASE-1080
> URL: https://issues.apache.org/jira/browse/MRELEASE-1080
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: perform, prepare
>Affects Versions: 3.0.0-M5
> Environment: Windows 10, Git for Windows Bourne Again Shell, Maven 
> 3.8.4
>Reporter: Mirko Klemm
>Priority: Major
>  Labels: exit, shell
> Fix For: waiting-for-feedback
>
>
> When doing a "release:prepare" or "release:perform", the maven process always 
> exits with a shell exit status of 1, even when the goal has finished with a 
> "BUILD SUCCESS" message, where it actually should return 0.
> This doesn't seem to have been the case with 2.x versions of the plugin.
> This is an important bug since it messes up using maven and the release 
> plugin in shell scripts.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (MRELEASE-1080) Maven v3.8.4 exits with non-zero status from release:perform or :prepare even when successful



 [ 
https://issues.apache.org/jira/browse/MRELEASE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mirko Klemm updated MRELEASE-1080:
--
Summary: Maven v3.8.4 exits with non-zero status from release:perform or 
:prepare even when successful  (was: Maven v3.8.0 exits with non-zero status 
from release:perform or :prepare even when successful)

> Maven v3.8.4 exits with non-zero status from release:perform or :prepare even 
> when successful
> -
>
> Key: MRELEASE-1080
> URL: https://issues.apache.org/jira/browse/MRELEASE-1080
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: perform, prepare
>Affects Versions: 3.0.0-M5
> Environment: Windows 10, Git for Windows Bourne Again Shell
>Reporter: Mirko Klemm
>Priority: Major
>  Labels: exit, shell
> Fix For: waiting-for-feedback
>
>
> When doing a "release:prepare" or "release:perform", the maven process always 
> exits with a shell exit status of 1, even when the goal has finished with a 
> "BUILD SUCCESS" message, where it actually should return 0.
> This doesn't seem to have been the case with 2.x versions of the plugin.
> This is an important bug since it messes up using maven and the release 
> plugin in shell scripts.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (MRELEASE-1080) Maven v3.8.0 exits with non-zero status from release:perform or :prepare even when successful



[ 
https://issues.apache.org/jira/browse/MRELEASE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504251#comment-17504251
 ] 

Mirko Klemm commented on MRELEASE-1080:
---

OK - now upgraded to Maven 3.8.4. Behaviour is identical to earlier Maven 
versions.

> Maven v3.8.0 exits with non-zero status from release:perform or :prepare even 
> when successful
> -
>
> Key: MRELEASE-1080
> URL: https://issues.apache.org/jira/browse/MRELEASE-1080
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: perform, prepare
>Affects Versions: 3.0.0-M5
> Environment: Windows 10, Git for Windows Bourne Again Shell
>Reporter: Mirko Klemm
>Priority: Major
>  Labels: exit, shell
> Fix For: waiting-for-feedback
>
>
> When doing a "release:prepare" or "release:perform", the maven process always 
> exits with a shell exit status of 1, even when the goal has finished with a 
> "BUILD SUCCESS" message, where it actually should return 0.
> This doesn't seem to have been the case with 2.x versions of the plugin.
> This is an important bug since it messes up using maven and the release 
> plugin in shell scripts.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (MPOM-303) Rename property maven.plugin.tools.version to mavenPluginToolsVersion