date:20210704



kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873764177


   Please note my update at the end of 
https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758 
concerning differences in leftover zombie processes between cmd.exe and Git 
Bash. I also mentioned a Windows CLI tool to display a process tree.


-- 
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] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test

kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758

> You did not take my commit with the fix. Your HEAD commit in your
repository contains your tests without the fix. So it is quite irrelevant.

What are you talking about?

![image](https://user-images.githubusercontent.com/1537384/124403579-5efae800-dd61-11eb-818d-dac622c75d0b.png)

You should read my PR correctly. The PR of course builds on top of your
fixes, I branched it off of master. Please revert and merge my PR as prior art
instead. I did this work, you were simply recreating it. These are my commits
and I want them merged. If something is wrong with my PR, we can fix them, of
course. The other branch without the fixes simply shows what would happen if
* we overlooked an edge case or
* accidentally the problem gets re-introduced in the future by someone
else's change or refactoring.

This IT (like all tests) is meant to do two things:
* verify some assumptions about how the application should behave
* reproduce a problem, spotting regressions, in case it does not behave as
expected

So, testing what would happen if the test actually _would_ run into a
timeout due to a regression is very much relevant. I simply created the other
branch for your convenience, so you can reproduce the problem with hanging JVMs
not being cleaned up properly. That other branch is not a PR branch, this one
is!

> Nobody is watching Windows task manager in order to send some proves
because this is false representation.

Of course not, normally people just run the IT, relying on it behaving
correctly. Cleaning up resources and fixtures is part of a test's correct
behaviour, and I manually verified that for you. I noticed that resource
clean-up is broken, which is why it should be fixed, because otherwise people
**not** looking at a task manager or `htop` would never notice what is going
on, until all the running processes from repeatedly running tests would cause
out of memory errors on their workstations or CI servers.

> Instead, the developers use the command-line

So the fact that I used a GUI tool from SysInternals disqualifies me as a
developer? It proves what? That you are a real developer and I am not? Can you
be any more condescending?

Different developers use different tools. If the tool reveals the correct
information, why does it matter if I started it from a console or from an IDE?
Besides, **I did run the test from Maven(!),** simply used a GUI tool to watch
what Maven does, live while it was happening. In that tool, I cannot just see
the end result but also what happens during the test: First, each of the two
Java process groups are indirect children of sh.exe (my Git Bash), which starts
the Maven build. Then, each time one of the two tests is interrupted due to the
timeouts, the subprocesses lose their parent (of course) and now move up the
process hierarchy, hanging there as zombies without parents. Your `wmic`
command only shows a subset of the same information, because the fact is
missing that it is not just Java processes but a group of 4 processes per test
case. My simple screenshot illustrates that way better.

You made a similar argument about my Process Explorer screenshot in the
original Jira ticket, trying to fend off my information as irrelevant, claiming
the Java agent to be the problem instead of Surefire. Like back then, you are
also wrong in this case: The problem is real, my screenshot illustrates it, and
you can easily reproduce it in my test branch. Of course, currently there is no
known regression, but no software is perfect and regressions can always occur.
To ensure that the ITs clean up their resources in case they fail due to a
hanging JVM (which is exactly what they test should **not** happen), is part of
the job of writing tests. So the job is not done yet.

But if it makes you happy, I replayed again on the console for you (ran
inside the IT module after a previous full build with install):

```none
$ mvn -P run-its verify
(...)
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running org.apache.maven.surefire.its.jiras.Surefire1881IT
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed:
60.054 s <<< FAILURE! - in org.apache.maven.surefire.its.jiras.Surefire1881IT
[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJVMLogging
Time elapsed: 30.011 s <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 3
milliseconds
at
app//org.apache.maven.surefire.its.jiras.Surefire1881IT.testJVMLogging(Surefire1881IT.java:37)

[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent
Time elapsed:

[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test

kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758

> You did not take my commit with the fix. Your HEAD commit in your
repository contains your tests without the fix. So it is quite irrelevant.

What are you talking about?

![image](https://user-images.githubusercontent.com/1537384/124403579-5efae800-dd61-11eb-818d-dac622c75d0b.png)

> Nobody is watching Windows task manager in order to send some proves
because this is false representation.

> Instead, the developers use the command-line

So the fact that I used a GUI tool from SysInternals disqualifies me as a
developer? It proves what? That you are a real developer and I am not? Can you
be any more condescending?

But if it makes you happy, I replayed again on the console for you (ran
inside the IT module after a previous full build with install):

[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent
Time elapsed:

[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test

kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758

> You did not take my commit with the fix. Your HEAD commit in your
repository contains your tests without the fix. So it is quite irrelevant.

What are you talking about?

![image](https://user-images.githubusercontent.com/1537384/124403579-5efae800-dd61-11eb-818d-dac622c75d0b.png)

> Nobody is watching Windows task manager in order to send some proves
because this is false representation.

> Instead, the developers use the command-line

So the fact that I used a GUI tool from SysInternals disqualifies me as a
developer? It proves what? That you are a real developer and I am not? Can you
be any more condescending?

But if it makes you happy, I replayed again on the console for you (ran
inside the IT module after a previous full build with install):

[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent
Time elapsed:

[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test

kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758

> You did not take my commit with the fix. Your HEAD commit in your
repository contains your tests without the fix. So it is quite irrelevant.

What are you talking about?

![image](https://user-images.githubusercontent.com/1537384/124403579-5efae800-dd61-11eb-818d-dac622c75d0b.png)

> Nobody is watching Windows task manager in order to send some proves
because this is false representation.

> Instead, the developers use the command-line

So the fact that I used a GUI tool from SysInternals disqualifies me as a
developer? It proves what? That you are a real developer and I am not? Can you
be any more condescending?

You made a similar argument about my Process Explorer screenshot in the
original Jira ticket, trying to fend off my information as irrelevant, claiming
the Java agent to be the problem instead of Surefire. Like back then, you are
also wrong in this case: The problem is real, my screenshot illustrates it you
can easily reproduce it in my test branch. Of course, currently there is no
known regression, but no software is perfect and regressions can always occur.
To ensure that the ITs clean up their resources in case they fail due to a
hanging JVM (which is exactly what they test should **not** happen), is part of
the job of writing tests. So the job is not done yet.

But if it makes you happy, I replayed again on the console for you (ran
inside the IT module after a previous full build with install):

[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent
Time elapsed: 30.011 s

[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test

kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758

> You did not take my commit with the fix. Your HEAD commit in your
repository contains your tests without the fix. So it is quite irrelevant.

What are you talking about?

![image](https://user-images.githubusercontent.com/1537384/124403579-5efae800-dd61-11eb-818d-dac622c75d0b.png)

> Nobody is watching Windows task manager in order to send some proves
because this is false representation.

> Instead, the developers use the command-line

So the fact that I used a GUI tool from SysInternals disqualifies me as a
developer? It proves what? That you are a real developer and I am not? Can you
be any more condescending?

Different developers use different tools. If the tool reveals the correct
information, why does it matter if I started it from a console or from an IDE?
Besides, **I did run the test from Maven(!),** simply used a GUI tool to watch
what Maven does live. In that tool, I cannot just see the end result but also
what happens during the test: First, each of the two Java process groups are
indirect children of sh.exe (my Git Bash), which starts the Maven build. Then,
each time one of the two tests is interrupted due to the timeouts, the
subprocesses lose their parent (of course) and now move up the process
hierarchy, hanging there as zombies without parents. Your `wmic` command only
shows a subset of the same information, because the fact is missing that it is
not just Java processes but a group of 4 processes per test case. My simple
screenshot illustrates that way better.

You made a similar argument about my Process Explorer screenshot in the
original Jira ticket, trying to fend off my information as irrelevant, claiming
the Java agent to be the problem instead of Surefire. Like back then, you are
also wrong in this case: The problem is real, my screenshot illustrates it you
can easily reproduce it in my test branch. Of course, currently there is no
known regression, but no software is perfect and regressions can always occur.
To ensure that the ITs clean up their resources in case they fail due to a
hanging JVM (which is exactly what they test should **not** happen), is part of
the job of writing tests. So the job is not done yet.

But if it makes you happy, I replayed again on the console for you (ran
inside the IT module after a previous full build with install):

[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent
Time elapsed: 30.011 s <<< ERROR!

[GitHub] [maven-surefire] kriegaex commented on pull request #355: [SUREFIRE-1881] - Fix and extend integration test



kriegaex commented on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873766789


   I just found https://issues.apache.org/jira/browse/MSHARED-867 and left a 
comment. It could be related to the problem described here.


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

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

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

[jira] [Commented] (MSHARED-867) Timed out processes can stay alive in background

2021-07-04 Thread Alexander Kriegisch (Jira)



[ 
https://issues.apache.org/jira/browse/MSHARED-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374490#comment-17374490
 ] 

Alexander Kriegisch commented on MSHARED-867:
-

I have a similar case in an integration test from the Maven Surefire project, 
see [here|https://github.com/apache/maven-surefire/pull/355] for more details 
and a reproducer. In this case, Failsafe runs the test, not Invoker. But for 
process execution, also Maven Shared Utils 3.1.0 is used, so this is probably 
the same issue. It would be nice if you could take a look.

Attention: The linked PR as such does not reproduce the problem, but the branch 
mentioned there, porting back the IT to a state before a certain Surefire bug 
was fixed, reproduces the problem. It was simply meant to verify that the same 
test would successfully terminate all child processes in case of a hanging test 
JVM. Unexpectedly, I reproducibly found leftover console and Java processes, at 
least on Windows (did not check other OS types yet). So I investigated if this 
is a known problem and found this issue.

> Timed out processes can stay alive in background
> 
>
> Key: MSHARED-867
> URL: https://issues.apache.org/jira/browse/MSHARED-867
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-invoker
>Affects Versions: maven-invoker-3.0.1
> Environment: Windows, Java 8
>Reporter: Robert Scholte
>Priority: Major
>
> MSHARED-795 introduced a timeout for processes, but on Windows I can see Java 
> processes staying alive, Maven Invoker just continues without forcing them to 
> stop.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-surefire] kriegaex commented on pull request #355: [SUREFIRE-1881] - Fix and extend integration test



kriegaex commented on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873764177


   Please note my update at the end of 
https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758 
concerning differences in leftover zombie processes between cmd.exe and Git 
Bash.


-- 
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] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test

kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758

> You did not take my commit with the fix. Your HEAD commit in your
repository contains your tests without the fix. So it is quite irrelevant.

What are you talking about?

![image](https://user-images.githubusercontent.com/1537384/124403579-5efae800-dd61-11eb-818d-dac622c75d0b.png)

> Nobody is watching Windows task manager in order to send some proves
because this is false representation.

> Instead, the developers use the command-line

So because I used a GUI tool from SysInternals disqualifies me as a
developer? It proves what? That you are a real developer and I am not? Can you
be any more condescending?

Different developers use different tools. If the tool reveals the correct
information, why does it matter if I started it from a console or from an IDE?
Besides, **I did run the test from Maven(!),** simply used a GUI tool to watch
what Maven does live. In that tool, I cannot just see the end result but also
what happens during the test: First, each of the two Java process groups are
indirect children of sh.exe (my Git Bash), which starts the Maven build. Then,
each time one of the two tests is interrupted due to the timeouts, the
subprocesses lose their parent (of course) and now move up the process
hierarchy, hanging there as zombies without parents. Your `wmic` command only
shows a subset of the same information, because the fact is missing that it is
not just Java processes but a group of 4 processes per test case. My simple
screenshot illustrates that way better.

You made a similar argument about my Process Explorer screenshot in the
original Jira ticket, trying to fend off my information as irrelevant, claiming
the Java agent to be the problem instead of Surefire. Like back then, you are
also wrong in this case: The problem is real, my screenshot illustrates it you
can easily reproduce it in my test branch. Of course, currently there is no
known regression, but no software is perfect and regressions can always occur.
To ensure that the ITs clean up their resources in case they fail due to a
hanging JVM (which is exactly what they test should **not** happen), is part of
the job of writing tests. So the job is not done yet.

But if it makes you happy, I replayed again on the console for you (ran
inside the IT module after a previous full build with install):

[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent
Time elapsed: 30.011 s <<< ERROR!

[jira] [Updated] (MJAVADOC-682) Reactor builds fail when multiple modules with same groupId:artifactId

2021-07-04 Thread AO Industries, Inc. (Jira)



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

AO Industries, Inc. updated MJAVADOC-682:
-
Description: 
In versions 3.1.0 through 3.3.0, when a reactor build has multiple projects 
with the same groupId and artifactId, even when different versions, the javadoc 
fails with:

Exit code: 1 - error: module not found: com.aoindustries.example

Plugin 3.0.1 works.

We have created a minimal example project that demonstrates this bug:

[https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name]

 

— Copy from demo project README.md —
h2. To Reproduce:
 # Clone this project: {{git clone 
[https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name.git]}}
 # Change to project directory: {{cd 
maven-javadoc-plugin-failing-multiple-projects-same-name}}
 # Perform build to see error in {{jar}} goal: {{mvn verify}}
 # Also fails with {{javadoc}} goal: {{mvn clean compile javadoc:javadoc}}

h2. Notes:
 * Can build individual modules directly, such as {{(cd module-1 && mvn 
verify)}}
 * Reverting to maven-javadoc-plugin version 3.0.1 makes it work
 * Changing the groupId or artifactId in either module-1 or module-2 makes it 
work.
 * Changing module names, package names, or class names in modules has no 
effect.
 * We believe this to be distinct from [Issue 
#673|https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-673]

  was:
In versions 3.1.0 through 3.3.0, when a reactor build has multiple projects 
with the same groupId and artifactId, even when different versions, the javadoc 
fails with:

Exit code: 1 - error: module not found: com.aoindustries.example

Plugin 3.0.1 works.

We have created a minimal example project that demonstrates this bug:

[https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name]

 

--- Copy from demo project README.md ---
h2. To Reproduce:
 # Clone this project: {{git clone 
[https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name.git]}}
 # Change to project directory: {{cd 
maven-javadoc-plugin-failing-multiple-projects-same-name}}
 # Perform build to see error in {{jar}} goal: {{mvn verify}}
 # Also fails with {{javadoc}} goal: {{mvn clean compile javadoc:javadoc}}

h2. Notes:
 * Can build individual modules directly, such as {{(cd module-1 && mvn 
verify)}}
 * Reverting to maven-javadoc-plugin version 3.0.1 makes it work
 * Changing the groupId or artifactId in either module-1 or module-2 makes it 
work.
 * Changing module names, package names, or class names in modules has no 
affect.
 * We believe this to be distinct from [Issue 
#673|https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-673]


> Reactor builds fail when multiple modules with same groupId:artifactId
> --
>
> Key: MJAVADOC-682
> URL: https://issues.apache.org/jira/browse/MJAVADOC-682
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>  Components: jar, javadoc
>Affects Versions: 3.1.0, 3.1.1, 3.2.0, 3.3.0
> Environment: Debian Linux 10.10, Java 11.0.11, Maven 3.8.1
>Reporter: AO Industries, Inc.
>Priority: Major
>
> In versions 3.1.0 through 3.3.0, when a reactor build has multiple projects 
> with the same groupId and artifactId, even when different versions, the 
> javadoc fails with:
> Exit code: 1 - error: module not found: com.aoindustries.example
> Plugin 3.0.1 works.
> We have created a minimal example project that demonstrates this bug:
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name]
>  
> — Copy from demo project README.md —
> h2. To Reproduce:
>  # Clone this project: {{git clone 
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name.git]}}
>  # Change to project directory: {{cd 
> maven-javadoc-plugin-failing-multiple-projects-same-name}}
>  # Perform build to see error in {{jar}} goal: {{mvn verify}}
>  # Also fails with {{javadoc}} goal: {{mvn clean compile javadoc:javadoc}}
> h2. Notes:
>  * Can build individual modules directly, such as {{(cd module-1 && mvn 
> verify)}}
>  * Reverting to maven-javadoc-plugin version 3.0.1 makes it work
>  * Changing the groupId or artifactId in either module-1 or module-2 makes it 
> work.
>  * Changing module names, package names, or class names in modules has no 
> effect.
>  * We believe this to be distinct from [Issue 
> #673|https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-673]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MPH-175) mvn help:effective-pom leaves pom in place

2021-07-04 Thread Georg Lippold (Jira)

Georg Lippold created MPH-175:
-

 Summary: mvn help:effective-pom leaves  pom in place
 Key: MPH-175
 URL: https://issues.apache.org/jira/browse/MPH-175
 Project: Maven Help Plugin
  Issue Type: Bug
  Components: effective-pom
Affects Versions: 3.2.0
 Environment: MacOS
Reporter: Georg Lippold


When executing mvn help:effective-pom, the  XML node is left intact. 
The  should be removed in the effective POM.

If you generate the effective pom to modify the project, e.g. to remove or 
override settings that are present in the parent pom, then including the 
 node in the resulting XML re-introduces the settings that you wanted 
to modify.

Example:  specifies a setting, e.g.





HTML





If the  node is now removed from the effective POM, then it is 
re-introduced by including the  in every maven run. The parent POM 
should not be required anymore in an effective POM, because all its settings 
should already be included in the effective POM.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test

kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873712057

> Here is the [history
](https://github.com/kriegaex/maven-surefire/commits/before-SUREFIRE-1881)of
commits in your repo - no fix!

You don't get it, do you? This PR (branch `SUREFIRE-1881-fix` ) does contain
the fixes! Branch `before-SUREFIRE-1881` is just for reproducing what would
happen in case of a regression, because I needed a way to emulate that
situation. What is so difficult to understand about it? This is why I named the
other branch accordingly, with an explicit `before-` prefix in the branch name,
and described it as a **backport**:

> If you want to easily reproduce the hanging JVMs directly in Surefire ITs,
**I ported both SUREFIRE-1881 tests from this PR back to the state before the
merge.** Simply check out my branch
[`before-SUREFIRE-1881`](https://github.com/kriegaex/maven-surefire/tree/before-SUREFIRE-1881),
make a clean build without tests and then run the ITs. The easiest way is to
temporarily add `Surefire1881IT` to the Failsafe config in the IT
module. Of course you can also add the corresponding Maven CLI option.

--
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] kriegaex commented on pull request #355: [SUREFIRE-1881] - Fix and extend integration test



kriegaex commented on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873712057


   > Here is the [history 
](https://github.com/kriegaex/maven-surefire/commits/before-SUREFIRE-1881)of 
commits in your repo - no fix!
   
   You don't get it, do you? This PR (branch `SUREFIRE-1881-fix` ) does contain 
the fixes! Branch `before-SUREFIRE-1881` is just for reproducing what would 
happen in case of a regression, because I needed a way to emulate that 
situation. What is so difficult to understand about it? This is why I named the 
other branch accordingly, with an explicit `before-` prefix in the branch name, 
and described it as a backport.


-- 
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] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test

kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758

> You did not take my commit with the fix. Your HEAD commit in your
repository contains your tests without the fix. So it is quite irrelevant.

What are you talking about?

![image](https://user-images.githubusercontent.com/1537384/124403579-5efae800-dd61-11eb-818d-dac622c75d0b.png)

> Nobody is watching Windows task manager in order to send some proves
because this is false representation.

> Instead, the developers use the command-line

So because I used a GUI tool from SysInternals disqualifies me as a
developer? It proves what? That you are a real developer and I am not? Can you
be any more condescending?

Different developers use different tools. If the tool reveals the correct
information, why does it matter if I started it from a console or from an IDE?
Besides, **I did run the test from Maven(!),** simply used a GUI tool to watch
what Maven does live. In that tool, I cannot just see the end result but also
what happens during the test: First, each of the two Java process groups are
indirect children of sh.exe (my Git Bash), which starts the Maven build. Then,
each time one of the two tests is interrupted due to the timeouts, the
subprocesses lose their parent (of course) and now move up the process
hierarchy, hanging there as zombies without parents. Your `wmic` command only
shows a subset of the same information, because the fact is missing that it is
not just Java processes but a group of 4 processes per test case. My simple
screenshot illustrates that way better.

You made a similar argument about my Process Explorer screenshot in the
original Jira ticket, trying to fend off my information as irrelevant, claiming
the Java agent to be the problem instead of Surefire. Like back then, you are
also wrong in this case: The problem is real, my screenshot illustrates it you
can easily reproduce it in my test branch. Of course, currently there is no
known regression, but no software is perfect and regressions can always occur.
To ensure that the ITs clean up their resources in case they fail due to a
hanging JVM (which is exactly what they test should **not** happen), is part of
the job of writing tests. So the job is not done yet.

But if it makes you happy, I replayed again on the console for you (ran
inside the IT module after a previous full build with install):

[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent
Time elapsed: 30.011 s <<< ERROR!

[GitHub] [maven-surefire] Tibor17 commented on pull request #355: [SUREFIRE-1881] - Fix and extend integration test



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


   @kriegaex 
   Here is the [history 
](https://github.com/kriegaex/maven-surefire/commits/before-SUREFIRE-1881)of 
commits in your repo - no fix!
   T


-- 
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] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test

kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758

> You did not take my commit with the fix. Your HEAD commit in your
repository contains your tests without the fix. So it is quite irrelevant.

What are you talking about?

![image](https://user-images.githubusercontent.com/1537384/124403579-5efae800-dd61-11eb-818d-dac622c75d0b.png)

> Nobody is watching Windows task manager in order to send some proves
because this is false representation.

> Instead, the developers use the command-line

Different developers use different tools. If the tool reveals the correct
information, why does it matter if I started it from a console or from an IDE?
Besides, I did run the test from Maven(!), simply used a GUI tool to watch what
Maven does live. In that tool, I cannot just see the end result but also what
happens during the test: First, each of the two Java process groups are
indirect children of sh.exe (my Git Bash), which starts the Maven build. Then,
each time one of the two tests is interrupted due to the timeouts, the
subprocesses lose their parent (of course) and now move up the process
hierarchy, hanging there as zombies without parents. Your `wmic` shows the same
information, only with less detail, because the fact that it is not just Java
processes but a group of 4 processes per test case is missing. My simple
screenshot illustrates that way better.

You made a similar argument about my Process Explorer screenshot in the
original Jira ticket, trying to fend off my information as irrelevant, claiming
the Java agent to be the problem instead of Surefire. Like back then, you are
also wrong in this case: The problem is real, my screenshot illustrates it you
can easily reproduce it in my test branch. Of course, currently there is no
known regression, but no software is perfect and regressions can always occur.
To ensure that the ITs clean up their resources in case they fail due to a
hanging JVM (which is exactly what they test should **not** happen), is part of
the job of writing tests. So the job is not done yet.

But if it makes you happy, I replayed again on the console for you (ran
inside the IT module after a previous full build with install):

[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent
Time elapsed: 30.011 s <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 3
milliseconds
at
app//org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent(Surefire1881IT.java:47)

[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test

kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758

> You did not take my commit with the fix. Your HEAD commit in your
repository contains your tests without the fix. So it is quite irrelevant.

What are you talking about?

![image](https://user-images.githubusercontent.com/1537384/124403579-5efae800-dd61-11eb-818d-dac622c75d0b.png)

> Nobody is watching Windows task manager in order to send some proves
because this is false representation.

> Instead, the developers use the command-line

You made a similar argument about my Process Explorer screenshot in the
original Jira ticket, trying to fend off my information as irrelevant, claiming
the Java agent to be the problem instead of Surefire. Like back then, you are
also wrong in this case: The problem is real, my screenshot illustrates it you
can easily reproduce it in my test branch. Of course, currently there is no
known regression, but no software is perfect and regressions can always occur.
To ensure that the ITs clean up their resources in case they fail due to a
hanging JVM (which is exactly what they test should **not** happen), is part of
the job of writing tests. So the job is not done yet.

But if it makes you happy, I replayed again on the console for you (ran
inside the IT module after a previous full build with install):

[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test

kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758

> You did not take my commit with the fix. Your HEAD commit in your
repository contains your tests without the fix. So it is quite irrelevant.

What are you talking about?

![image](https://user-images.githubusercontent.com/1537384/124403579-5efae800-dd61-11eb-818d-dac622c75d0b.png)

You should read my PR correctly. The PR of course builds on top of your
fixes, I branched it off of master. Please revert and merge my PR as prior art
instead. I did this work, you were simply recreating it. These are my commits
and I want them merged. If something is wrong with my PR, we can fix them, of
course. The other branch without the fixes simply shows what would happen if
* we overlooked an endge case or
* accidentally the problem gets re-introduced in the future by someone
elses change or refactoring.

This IT is meant to do two things:
* verify some assumptions about how the application should behave
* reproduce a problem, spotting regressions, in case it does not behave as
expected

So testing what would happen if the test actually would run into a timeout
due to a regression is very much relevant. I simply created the other branch
for your convenience, so you can reproduce the problem with hanging JVMs not
being cleaned up properly. That other branch is not a PR branch, this one is!

> Nobody is watching Windows task manager in order to send some proves
because this is false representation.

> Instead, the developers use the command-line

You made a similar argument about my Process Explorer screenshot in the
original Jira ticket, trying to fend off my information as irrelevant, claiming
the Java agent to be the problem instead of Surefire. Like back then, you are
also wrong in this case: The problem is real, my screenshot illustrates it you
can easily reproduce it in my test branch. Of course, currently there is no
known regression, but no software is perfect and regressions can always occur.
To ensure that the ITs clean up their resources in case they fail due to a
hanging JVM (which is exactly what they test should **not** happen), is part of
the job of writing tests. So the job is not done yet.

But if it makes you happy, I replayed again on the console for you (ran
inside the IT module after a previous full build with install):

[INFO]
[INFO]

[GitHub] [maven-surefire] kriegaex commented on pull request #355: [SUREFIRE-1881] - Fix and extend integration test

kriegaex commented on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758

> You did not take my commit with the fix. Your HEAD commit in your
repository contains your tests without the fix. So it is quite irrelevant.

What are you talking about?

![image](https://user-images.githubusercontent.com/1537384/124403579-5efae800-dd61-11eb-818d-dac622c75d0b.png)

You should read my PR correctly. The PR of course builds on top of your
fixes, I branched it off of master. Please revert and merge my PR as prior art
instead I did this work, you were simply recreating it. These are my commits
and I want them merged. If something is wrong with my PR, we can fix them, of
course. The other branch without the fixes simply shows what would happen if
* we overlooked an endge case or
* accidentally the problem gets re-introduced in the future by someone
elses change or refactoring.

This IT is meant to do two things:
* verify some assumptions about how the application should behave
* reproduce a problem, spotting regressions, in case it does not behave as
expected

> Nobody is watching Windows task manager in order to send some proves
because this is false representation.

> Instead, the developers use the command-line

You made a similar argument about my Process Explorer screenshot in the
original Jira ticket, trying to fend off my information as irrelevant, claiming
the Java agent to be the problem instead of Surefire. Like back then, you are
also wrong in this case: The problem is real, my screenshot illustrates it you
can easily reproduce it in my test branch. Of course, currently there is no
known regression, but no software is perfect and regressions can always occur.
To ensure that the ITs clean up their resources in case they fail due to a
hanging JVM (which is exactly what they test should **not** happen), is part of
the job of writing tests. So the job is not done yet.

But if it makes you happy, I replayed again on the console for you (ran
inside the IT module after a previous full build with install):

[INFO]
[INFO] Results:

[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test



Tibor17 edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873688965


   @kriegaex 
   You did not take my commit with the fix. Your HEAD commit in your repository 
contains your tests without the fix. So it is quite irrelevant.
   [I renamed the 
IT](https://github.com/apache/maven-surefire/commit/4a43a400eb52abaf5a833c814050c18ebc4ef421)
 in **master** and [added the unit 
test](https://github.com/apache/maven-surefire/commit/aff6eebe59721ac3c318e277aaba711aca55aee6)
 similar you did here. Nobody is watching Windows task manager in order to send 
some proves because this is false representation. Instead, the developers use 
the command-line and precisely understand the console. Pls use this during and 
after the test in command-line. Do not use any IDE, use only console/cmd on 
your Windows system, as follows (includes real outcome during the test on [your 
test 
project](https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems)).
   
   ```
   wmic PROCESS where "name like '%java%'" get Commandline
   
   CommandLine
   
   "c:\Program Files\Java\jdk1.8.0_281\bin\java.exe" -classpath 
"c:\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar"   
"-Dclassworlds.conf=c:\apache-maven-3.6.3\bin\..\bin\m2.conf"   
"-Dmaven.home=c:\apache-maven-3.6.3\bin\.."   
"-Dlibrary.jansi.path=c:\apache-maven-3.6.3\bin\..\lib\jansi-native"   
"-Dmaven.multiModuleProjectDirectory=C:\vcs\github\Maven_Surefire_PrintToConsoleProblems"
   org.codehaus.plexus.classworlds.launcher.Launcher -o verify 
   
   "c:\Program Files\Java\jdk1.8.0_281\jre\bin\java"  
-javaagent:C:\vcs\github\Maven_Surefire_PrintToConsoleProblems\target/surefire-print-console-problems-1.0-SNAPSHOT.jar
 -jar 
C:\Users\tibor17\AppData\Local\Temp\surefire7956139842988037439\surefirebooter1388721399876762247.jar
 C:\Users\tibor17\AppData\Local\Temp\surefire7956139842988037439 
2021-07-05T00-07-45_319-jvmRun1 surefire2890232333274079753tmp 
surefire_07190630157758286269tmp
   ```


-- 
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 #355: [SUREFIRE-1881] - Fix and extend integration test



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


   @kriegaex 
   You did not take my commit with the fix. Your HEAD commit in your repository 
contains your tests without the fix. So it is quite irrelevant.
   [I renamed the 
IT](https://github.com/apache/maven-surefire/commit/4a43a400eb52abaf5a833c814050c18ebc4ef421)
 in **master** and added the unit test as you did. Nobody is watching Windows 
task manager in order to send some proves because this is false representation. 
Instead, the developers use the command-line and precisely understand the 
console. Pls use this during and after the test in command-line. Do not use any 
IDE, use only console/cmd on your Windows system, as follows (includes real 
outcome during the test on [your test 
project](https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems)).
   
   ```
   wmic PROCESS where "name like '%java%'" get Commandline
   
   CommandLine
   
   "c:\Program Files\Java\jdk1.8.0_281\bin\java.exe" -classpath 
"c:\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar"   
"-Dclassworlds.conf=c:\apache-maven-3.6.3\bin\..\bin\m2.conf"   
"-Dmaven.home=c:\apache-maven-3.6.3\bin\.."   
"-Dlibrary.jansi.path=c:\apache-maven-3.6.3\bin\..\lib\jansi-native"   
"-Dmaven.multiModuleProjectDirectory=C:\vcs\github\Maven_Surefire_PrintToConsoleProblems"
   org.codehaus.plexus.classworlds.launcher.Launcher -o verify 
   
   "c:\Program Files\Java\jdk1.8.0_281\jre\bin\java"  
-javaagent:C:\vcs\github\Maven_Surefire_PrintToConsoleProblems\target/surefire-print-console-problems-1.0-SNAPSHOT.jar
 -jar 
C:\Users\tibor17\AppData\Local\Temp\surefire7956139842988037439\surefirebooter1388721399876762247.jar
 C:\Users\tibor17\AppData\Local\Temp\surefire7956139842988037439 
2021-07-05T00-07-45_319-jvmRun1 surefire2890232333274079753tmp 
surefire_07190630157758286269tmp
   ```


-- 
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-invoker-plugin] slawekjaranowski opened a new pull request #49: [MINVOKER-273] Environment variable with empty value



slawekjaranowski opened a new pull request #49:
URL: https://github.com/apache/maven-invoker-plugin/pull/49


   After fix in `maven-shared-utils` we only need some tests for confirmation.


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

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

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

[GitHub] [maven-shade-plugin] michael-o commented on pull request #26: [MSHADE-326] Hide shaded dependencies from the rest of the reactor build



michael-o commented on pull request #26:
URL: https://github.com/apache/maven-shade-plugin/pull/26#issuecomment-873662333


   My personal opinion: A broken cache should be removed or improved. 
@rfscholte Remove or try to solve.


-- 
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 #485: [MNG-6241] Load -Dstyle.color from system properties also



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


   > I have a little bit of doubts about this. I see system properties as 
something for the JVM, whereas user properties are for Maven itself. (and yes, 
it looks weird because both use -Dkey=value, it all depends on where on the 
commandline these properties are).
   > These colors are more for Maven and not for the JVM.
   
   Absolutely true, but I see no other way at the moment. Otherwise we should 
close as wontfix.


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

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

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

[GitHub] [maven-shade-plugin] nielsbasjes commented on pull request #26: [MSHADE-326] Hide shaded dependencies from the rest of the reactor build



nielsbasjes commented on pull request #26:
URL: https://github.com/apache/maven-shade-plugin/pull/26#issuecomment-873648803


   @michael-o 
   1. Yes, this is indeed a hard problem with a lot of side effects to think 
about.
   2. I already did that check (as I mentioned in the description) with both 
3.8.1 and a maven that includes my patch; Note that it also passed the CI build.
   3. I'll leave this open for now.
   
   I read in the comments that someone had a single project with over 5000 
modules which in my experience sounds very extreme.
   Perhaps a monorepo that is also a single build?
   I checked the mentioned Apache Camel (586 pom.xml files) and some projects 
which I expected to have a large number of modules (just counted the pom.xml 
files): Flink (179), Hadoop (113), Nifi (592) and Spark (36)
   
   So my main question is to what extend should maven support so many modules?
   Even for very large projects having > 1000 modules seems like "too many".
   
   I'll see what I can do at the maven end to make a test for this.
   1) I read about the algorithms in maven that determine the actual build 
ordering that are affected by this change.
   At this point I do not have enough knowledge about this to come up with 
a test that verifies this behavior to remain correct.
   2) As far as I can tell the only way is to add something that changes the 
reactor build ... like the test of this pull request.
   Simply migrating this (now failing) test to maven would make the 
maven-shade-plugin a part of the tests in the maven build.
   Is this ok ? Or do you have a better proposal on how to reproduce this?
   
   


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

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

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

[GitHub] [maven] rfscholte commented on pull request #485: [MNG-6241] Load -Dstyle.color from system properties also



rfscholte commented on pull request #485:
URL: https://github.com/apache/maven/pull/485#issuecomment-873635336


   I have a little bit of doubts about this. I see system properties as 
something for the JVM, whereas user properties are for Maven itself. (and yes, 
it looks weird because both use -Dkey=value, it all depends on where on the 
commandline these properties are).
   These colors are more for Maven and not for the JVM.


-- 
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-7126) Maven option -nsu --no-snapshot-updates not working



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

Michael Osipov updated MNG-7126:

Fix Version/s: waiting-for-feedback

> Maven option -nsu --no-snapshot-updates not working
> ---
>
> Key: MNG-7126
> URL: https://issues.apache.org/jira/browse/MNG-7126
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows/Linux. Doesn't seem to matter.
>Reporter: Bill
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: compass-next-X-output.txt.tar.gz
>
>
> Essentially the option seems to just not work.
> I found that the same issue outlines in the this Jira for Maven 3.0.3 still 
> applies to Maven 3.5.0: https://issues.apache.org/jira/browse/MNG-5064
> https://issues.apache.org/jira/browse/MNG-5064
> Here someone is mentioning still having the issue Maven 3.2.5: 
> [https://issues.maven.apache.narkive.com/gF3CQyTF/jira-commented-mng-5064-mvn-nsu-no-snapshot-updates-should-not-download-snapshots-and-break-local]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-7126) Maven option -nsu --no-snapshot-updates not working



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

Michael Osipov commented on MNG-7126:
-

[~b...@ciminc.com], do you think you can create a minimal project which 
exhibits the issue for you?

> Maven option -nsu --no-snapshot-updates not working
> ---
>
> Key: MNG-7126
> URL: https://issues.apache.org/jira/browse/MNG-7126
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows/Linux. Doesn't seem to matter.
>Reporter: Bill
>Priority: Major
> Attachments: compass-next-X-output.txt.tar.gz
>
>
> Essentially the option seems to just not work.
> I found that the same issue outlines in the this Jira for Maven 3.0.3 still 
> applies to Maven 3.5.0: https://issues.apache.org/jira/browse/MNG-5064
> https://issues.apache.org/jira/browse/MNG-5064
> Here someone is mentioning still having the issue Maven 3.2.5: 
> [https://issues.maven.apache.narkive.com/gF3CQyTF/jira-commented-mng-5064-mvn-nsu-no-snapshot-updates-should-not-download-snapshots-and-break-local]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-shade-plugin] michael-o commented on pull request #26: [MSHADE-326] Hide shaded dependencies from the rest of the reactor build



michael-o commented on pull request #26:
URL: https://github.com/apache/maven-shade-plugin/pull/26#issuecomment-873623496


   1. The fix from you is incomplete, at the end we likely need to revert 
d3ace78602405079d6416a63c13216568ba97995 (MNG-6638)
   2. Can you verify that adding the id also works with stock Maven w/o the fix?
   3. Makes sense
   
   See also objections in https://github.com/apache/maven/pull/69. We need to 
please both, invalidate cache when necessary, but use it as often as possible. 
The "hack" shouldn't stay forever. A better approach should be discussed after 
4.0.0-alpha-1.
   
   @nielsbasjes Can you work out a Maven IT which exposes the correct behavior 
and will fail for now. Then we will drop the hacks in a branch and will see how 
it performs?


-- 
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-7056) Replace tabs in IT files

2021-07-04 Thread Hudson (Jira)



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

Hudson commented on MNG-7056:
-

Build succeeded in Jenkins: Maven » Maven TLP » maven » master #181

See 
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/181/

> Replace tabs in IT files
> 
>
> Key: MNG-7056
> URL: https://issues.apache.org/jira/browse/MNG-7056
> Project: Maven
>  Issue Type: Task
>  Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> These files:
> {noformat}
> $ grep -rl '^I' . | sort -u | grep -v -e '.jar$' -e Makefile -e '.war$'
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3642DynamicResourcesTest.java
> ./core-it-suite/src/test/resources/bootstrap/group-11/pom.xml
> ./core-it-suite/src/test/resources/bootstrap/group-12/pom.xml
> ./core-it-suite/src/test/resources/it0038/pom.xml
> ./core-it-suite/src/test/resources/mng-0612/project/pom.xml
> ./core-it-suite/src/test/resources/mng-0773/settings.xml
> ./core-it-suite/src/test/resources/mng-2196/pom.xml
> ./core-it-suite/src/test/resources/mng-2289/issue/src/main/java/mng/Issue2289.java
> ./core-it-suite/src/test/resources/mng-2305/keystore
> ./core-it-suite/src/test/resources/mng-2771/project/pom.xml
> ./core-it-suite/src/test/resources/mng-2926/repo/org/apache/maven/its/mng2926/mng-2926/0.1/mng-2926-0.1.pom
> ./core-it-suite/src/test/resources/mng-2926/repo/org/apache/maven/plugins/mng-2926/0.1/mng-2926-0.1.pom
> ./core-it-suite/src/test/resources/mng-2926/repo/org/codehaus/mojo/mng-2926/0.1/mng-2926-0.1.pom
> ./core-it-suite/src/test/resources/mng-3203/src/main/java/org/apache/maven/it/mng3203/App.java
> ./core-it-suite/src/test/resources/mng-3203/src/main/java/org/apache/maven/it/mng3203/Diamond.java
> ./core-it-suite/src/test/resources/mng-3259/module1/pom.xml
> ./core-it-suite/src/test/resources/mng-3259/module1/src/main/java/mng/XStreamTestCase.java
> ./core-it-suite/src/test/resources/mng-3259/module2/pom.xml
> ./core-it-suite/src/test/resources/mng-3259/module2/src/main/java/mng/Module2.java
> ./core-it-suite/src/test/resources/mng-3259/module3/pom.xml
> ./core-it-suite/src/test/resources/mng-3259/module3/src/main/java/mng/Module3.java
> ./core-it-suite/src/test/resources/mng-3259/module3/src/test/java/mng/Module3TestUtil.java
> ./core-it-suite/src/test/resources/mng-3259/module4/pom.xml
> ./core-it-suite/src/test/resources/mng-3259/module4/src/main/java/mng/Module4.java
> ./core-it-suite/src/test/resources/mng-3259/module4/src/main/java/mng/Module4Bean.java
> ./core-it-suite/src/test/resources/mng-3259/module5/pom.xml
> ./core-it-suite/src/test/resources/mng-3259/module5/src/main/java/mng/Module5.java
> ./core-it-suite/src/test/resources/mng-3259/module5/src/test/java/mng/Module5Test.java
> ./core-it-suite/src/test/resources/mng-3259/parent/pom.xml
> ./core-it-suite/src/test/resources/mng-3372/dependency-tree/pom.xml
> ./core-it-suite/src/test/resources/mng-3506/mng-3506.1/src/main/java/org/apache/maven/its/mng3506/App.java
> ./core-it-suite/src/test/resources/mng-3506/mng-3506.1/src/test/java/org/apache/maven/its/mng3506/AppTest.java
> ./core-it-suite/src/test/resources/mng-3506/mng-3506.2/src/main/java/org/apache/maven/its/mng3506/App.java
> ./core-it-suite/src/test/resources/mng-3506/mng-3506.2/src/test/java/org/apache/maven/its/mng3506/AppTest.java
> ./core-it-suite/src/test/resources/mng-3652/test-plugin/pom.xml
> ./core-it-suite/src/test/resources/mng-3684/maven-mng3684-plugin/pom.xml
> ./core-it-suite/src/test/resources/mng-3693/maven-mng3693-plugin/pom.xml
> ./core-it-suite/src/test/resources/mng-3693/projects/app/pom.xml
> ./core-it-suite/src/test/resources/mng-3694/maven-mng3694-plugin/pom.xml
> ./core-it-suite/src/test/resources/mng-3694/maven-mng3694-plugin/src/main/java/plugin/MyMojo.java
> ./core-it-suite/src/test/resources/mng-3703/maven-mng3703-plugin/pom.xml
> ./core-it-suite/src/test/resources/mng-3704/maven-mng3704-plugin/pom.xml
> ./core-it-suite/src/test/resources/mng-3710/original-model/plugins/maven-mng3710-originalModel-plugin/pom.xml
> ./core-it-suite/src/test/resources/mng-3710/pom-inheritance/projects/middle/pom.xml
> ./core-it-suite/src/test/resources/mng-3716/projects/pom.xml
> ./core-it-suite/src/test/resources/mng-3723/maven-mng3723-plugin/pom.xml
> ./core-it-suite/src/test/resources/mng-3723/projects/pom.xml
> ./core-it-suite/src/test/resources/mng-3724/maven-mng3724-plugin/pom.xml
> ./core-it-suite/src/test/resources/mng-3743/plugins/maven-mng3743-report-plugin/pom.xml
> ./core-it-suite/src/test/resources/mng-3743/plugins/pom.xml
> ./core-it-suite/src/test/resources/mng-3814/plugin-a/pom.xml
>

[jira] [Commented] (MNG-6840) Upgrade commons-lang3 to 3.12.0

2021-07-04 Thread Hudson (Jira)



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

Hudson commented on MNG-6840:
-

Build succeeded in Jenkins: Maven » Maven TLP » maven » master #181

See 
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/181/

> Upgrade commons-lang3 to 3.12.0
> ---
>
> Key: MNG-6840
> URL: https://issues.apache.org/jira/browse/MNG-6840
> Project: Maven
>  Issue Type: Dependency upgrade
>  Components: core
>Affects Versions: 3.6.3
>Reporter: Krosheninnikov Artem
>Assignee: Michael Osipov
>Priority: Trivial
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> While it's not clear whether to remove/replace commons-lang dependency, it's 
> worth having it up-to-date



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-shade-plugin] michael-o edited a comment on pull request #26: [MSHADE-326] Hide shaded dependencies from the rest of the reactor build



michael-o edited a comment on pull request #26:
URL: https://github.com/apache/maven-shade-plugin/pull/26#issuecomment-864394719


   So I reviewed this PR, the JIRA issue as well as MSHADE-206 and MNG-5899 and 
I see a few issues here:
   * The description on the JIRA issue is wrong
   * From my PoV this PR only fixes the symptom, not the cause
   * Looking at this plugin's source code this change (regardless of cause or 
symptom) can only be applied if a DPR is created, i.e., this has to happen 
unconditionally in `rewriteDependencyReducedPomIfWeHaveReduction()` attaching a 
new POM with modified deps, but not modifying the dep list is inconsistent. 
   * So why does this only solve the symptom? If you look at the discussion in 
MSHADE-206 and MNG-5899 it refers to an old commit in Maven which introduced a 
hack with a simple cache which does not re-read POMs even if they have changed 
in-flight. There is no cache validation/eviction. Without haven't do any live 
testing and knowing how reasonable the cache performance gains are, one could 
consider dropping the cache. I always prefer consistent behavior over 
performance.
   
   I would like to ask the following: Please branch off Maven master, drop the 
hacky cache and retry w/o this PR and let me know whether this fixes the issue 
already for you. If so, we need to reconsider the cache. Maybe this new 
parameter can be introduced, but only as `@Deprecated` because it fixes the 
symptom only.
   
   @rfscholte Since you left a new comments on MNG-5899, do you think we could 
safely drop the cache and see whether we will see complains about performance 
drop?


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

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

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

[jira] [Closed] (MNG-6840) Upgrade commons-lang3 to 3.12.0



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

Michael Osipov closed MNG-6840.
---
Resolution: Fixed

Fixed with 
[1fc605dd69f99e91e0685a4f4ba279d2fd2eed21|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=1fc605dd69f99e91e0685a4f4ba279d2fd2eed21].

> Upgrade commons-lang3 to 3.12.0
> ---
>
> Key: MNG-6840
> URL: https://issues.apache.org/jira/browse/MNG-6840
> Project: Maven
>  Issue Type: Dependency upgrade
>  Components: core
>Affects Versions: 3.6.3
>Reporter: Krosheninnikov Artem
>Assignee: Michael Osipov
>Priority: Trivial
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> While it's not clear whether to remove/replace commons-lang dependency, it's 
> worth having it up-to-date



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven] asfgit closed pull request #308: MNG-6840 update commons-lang to 3.9



asfgit closed pull request #308:
URL: https://github.com/apache/maven/pull/308


   


-- 
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-6840) Upgrade commons-lang3 to 3.12.0



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

Michael Osipov updated MNG-6840:

Fix Version/s: 4.0.0-alpha-1
   4.0.0

> Upgrade commons-lang3 to 3.12.0
> ---
>
> Key: MNG-6840
> URL: https://issues.apache.org/jira/browse/MNG-6840
> Project: Maven
>  Issue Type: Dependency upgrade
>  Components: core
>Affects Versions: 3.6.3
>Reporter: Krosheninnikov Artem
>Assignee: Michael Osipov
>Priority: Trivial
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> While it's not clear whether to remove/replace commons-lang dependency, it's 
> worth having it up-to-date



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (MNG-6840) Upgrade commons-lang3 to 3.12.0



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

Michael Osipov reassigned MNG-6840:
---

Assignee: Michael Osipov

> Upgrade commons-lang3 to 3.12.0
> ---
>
> Key: MNG-6840
> URL: https://issues.apache.org/jira/browse/MNG-6840
> Project: Maven
>  Issue Type: Dependency upgrade
>  Components: core
>Affects Versions: 3.6.3
>Reporter: Krosheninnikov Artem
>Assignee: Michael Osipov
>Priority: Trivial
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> While it's not clear whether to remove/replace commons-lang dependency, it's 
> worth having it up-to-date



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MNG-6840) Upgrade commons-lang3 to 3.12.0



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

Michael Osipov updated MNG-6840:

Summary: Upgrade commons-lang3 to 3.12.0  (was: Update commons-lang3)

> Upgrade commons-lang3 to 3.12.0
> ---
>
> Key: MNG-6840
> URL: https://issues.apache.org/jira/browse/MNG-6840
> Project: Maven
>  Issue Type: Dependency upgrade
>  Components: core
>Affects Versions: 3.6.3
>Reporter: Krosheninnikov Artem
>Priority: Trivial
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> While it's not clear whether to remove/replace commons-lang dependency, it's 
> worth having it up-to-date



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-6241) Load -Dstyle.color from system properties also



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

Michael Osipov commented on MNG-6241:
-

Please check the PR. Works for me.

> Load -Dstyle.color from system properties also
> --
>
> Key: MNG-6241
> URL: https://issues.apache.org/jira/browse/MNG-6241
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Thorsten Glaser
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.x-candidate, 3.8.x-candidate
>
>
> Coloured output does not look very nice in a Jenkins logfile *and* breaks 
> some plugins we use, therefore I wish to disable it programmatically.
> However, looking at the source, I find it can only be disabled by passing the 
> command-line options -B or -l, but not from settings.xml or via MAVEN_OPTS in 
> the environment.
> I’ve worked around this by using dpkg-divert to move the mvn binary away and 
> placing this…
> {{{
> # cat /usr/share/maven/bin/mvn
> #!/bin/mksh-static
> exec /usr/share/maven/bin/mvn.dpkg-dist -B "$@"
> }}}
> … in its stead, but that’s creepy at best. Please implement a setting, 
> ideally for settings.xml *and* MAVEN_OPTS, to disable colour.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven] michael-o opened a new pull request #485: [MNG-6241] Load -Dstyle.color from system properties also



michael-o opened a new pull request #485:
URL: https://github.com/apache/maven/pull/485


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


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

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

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

[jira] [Assigned] (MNG-6241) Load -Dstyle.color from system properties also



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

Michael Osipov reassigned MNG-6241:
---

Assignee: Michael Osipov

> Load -Dstyle.color from system properties also
> --
>
> Key: MNG-6241
> URL: https://issues.apache.org/jira/browse/MNG-6241
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Thorsten Glaser
>Assignee: Michael Osipov
>Priority: Major
>
> Coloured output does not look very nice in a Jenkins logfile *and* breaks 
> some plugins we use, therefore I wish to disable it programmatically.
> However, looking at the source, I find it can only be disabled by passing the 
> command-line options -B or -l, but not from settings.xml or via MAVEN_OPTS in 
> the environment.
> I’ve worked around this by using dpkg-divert to move the mvn binary away and 
> placing this…
> {{{
> # cat /usr/share/maven/bin/mvn
> #!/bin/mksh-static
> exec /usr/share/maven/bin/mvn.dpkg-dist -B "$@"
> }}}
> … in its stead, but that’s creepy at best. Please implement a setting, 
> ideally for settings.xml *and* MAVEN_OPTS, to disable colour.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MNG-6241) Load -Dstyle.color from system properties also



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

Michael Osipov updated MNG-6241:

Fix Version/s: 3.8.x-candidate
   4.0.x-candidate

> Load -Dstyle.color from system properties also
> --
>
> Key: MNG-6241
> URL: https://issues.apache.org/jira/browse/MNG-6241
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Thorsten Glaser
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.x-candidate, 3.8.x-candidate
>
>
> Coloured output does not look very nice in a Jenkins logfile *and* breaks 
> some plugins we use, therefore I wish to disable it programmatically.
> However, looking at the source, I find it can only be disabled by passing the 
> command-line options -B or -l, but not from settings.xml or via MAVEN_OPTS in 
> the environment.
> I’ve worked around this by using dpkg-divert to move the mvn binary away and 
> placing this…
> {{{
> # cat /usr/share/maven/bin/mvn
> #!/bin/mksh-static
> exec /usr/share/maven/bin/mvn.dpkg-dist -B "$@"
> }}}
> … in its stead, but that’s creepy at best. Please implement a setting, 
> ideally for settings.xml *and* MAVEN_OPTS, to disable colour.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MNG-6241) Load -Dstyle.color from system properties also



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

Michael Osipov updated MNG-6241:

Summary: Load -Dstyle.color from system properties also  (was: colour 
output cannot be disabled from settings.xml or MAVEN_OPTS)

> Load -Dstyle.color from system properties also
> --
>
> Key: MNG-6241
> URL: https://issues.apache.org/jira/browse/MNG-6241
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Thorsten Glaser
>Priority: Major
>
> Coloured output does not look very nice in a Jenkins logfile *and* breaks 
> some plugins we use, therefore I wish to disable it programmatically.
> However, looking at the source, I find it can only be disabled by passing the 
> command-line options -B or -l, but not from settings.xml or via MAVEN_OPTS in 
> the environment.
> I’ve worked around this by using dpkg-divert to move the mvn binary away and 
> placing this…
> {{{
> # cat /usr/share/maven/bin/mvn
> #!/bin/mksh-static
> exec /usr/share/maven/bin/mvn.dpkg-dist -B "$@"
> }}}
> … in its stead, but that’s creepy at best. Please implement a setting, 
> ideally for settings.xml *and* MAVEN_OPTS, to disable colour.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MNG-6241) colour output cannot be disabled from settings.xml or MAVEN_OPTS



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

Michael Osipov updated MNG-6241:

Issue Type: Improvement  (was: Bug)

> colour output cannot be disabled from settings.xml or MAVEN_OPTS
> 
>
> Key: MNG-6241
> URL: https://issues.apache.org/jira/browse/MNG-6241
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Thorsten Glaser
>Priority: Major
>
> Coloured output does not look very nice in a Jenkins logfile *and* breaks 
> some plugins we use, therefore I wish to disable it programmatically.
> However, looking at the source, I find it can only be disabled by passing the 
> command-line options -B or -l, but not from settings.xml or via MAVEN_OPTS in 
> the environment.
> I’ve worked around this by using dpkg-divert to move the mvn binary away and 
> placing this…
> {{{
> # cat /usr/share/maven/bin/mvn
> #!/bin/mksh-static
> exec /usr/share/maven/bin/mvn.dpkg-dist -B "$@"
> }}}
> … in its stead, but that’s creepy at best. Please implement a setting, 
> ideally for settings.xml *and* MAVEN_OPTS, to disable colour.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-6241) colour output cannot be disabled from settings.xml or MAVEN_OPTS



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

Michael Osipov commented on MNG-6241:
-

Using settings is unfortunately not possible because it comes much later than 
the color configuration. See 
{{org.apache.maven.cli.MavenCli.doMain(CliRequest)}}. It would require us to 
first load the settings, get the flag and then process command line args.

What we could do it so extend the code to accept from system properties too.

System props => user props => command line option.

[~mirabilos], [~martinkanters], WDYT?

> colour output cannot be disabled from settings.xml or MAVEN_OPTS
> 
>
> Key: MNG-6241
> URL: https://issues.apache.org/jira/browse/MNG-6241
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Thorsten Glaser
>Priority: Major
>
> Coloured output does not look very nice in a Jenkins logfile *and* breaks 
> some plugins we use, therefore I wish to disable it programmatically.
> However, looking at the source, I find it can only be disabled by passing the 
> command-line options -B or -l, but not from settings.xml or via MAVEN_OPTS in 
> the environment.
> I’ve worked around this by using dpkg-divert to move the mvn binary away and 
> placing this…
> {{{
> # cat /usr/share/maven/bin/mvn
> #!/bin/mksh-static
> exec /usr/share/maven/bin/mvn.dpkg-dist -B "$@"
> }}}
> … in its stead, but that’s creepy at best. Please implement a setting, 
> ideally for settings.xml *and* MAVEN_OPTS, to disable colour.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (MNG-7056) Replace tabs in IT files



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

Michael Osipov closed MNG-7056.
---
  Assignee: Michael Osipov
Resolution: Fixed

Fixed with 
[be44f4a1a688141d979b1482eec45955ddc1a9c6|https://gitbox.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=be44f4a1a688141d979b1482eec45955ddc1a9c6].

> Replace tabs in IT files
> 
>
> Key: MNG-7056
> URL: https://issues.apache.org/jira/browse/MNG-7056
> Project: Maven
>  Issue Type: Task
>  Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> These files:
> {noformat}
> $ grep -rl '^I' . | sort -u | grep -v -e '.jar$' -e Makefile -e '.war$'
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3642DynamicResourcesTest.java
> ./core-it-suite/src/test/resources/bootstrap/group-11/pom.xml
> ./core-it-suite/src/test/resources/bootstrap/group-12/pom.xml
> ./core-it-suite/src/test/resources/it0038/pom.xml
> ./core-it-suite/src/test/resources/mng-0612/project/pom.xml
> ./core-it-suite/src/test/resources/mng-0773/settings.xml
> ./core-it-suite/src/test/resources/mng-2196/pom.xml
> ./core-it-suite/src/test/resources/mng-2289/issue/src/main/java/mng/Issue2289.java
> ./core-it-suite/src/test/resources/mng-2305/keystore
> ./core-it-suite/src/test/resources/mng-2771/project/pom.xml
> ./core-it-suite/src/test/resources/mng-2926/repo/org/apache/maven/its/mng2926/mng-2926/0.1/mng-2926-0.1.pom
> ./core-it-suite/src/test/resources/mng-2926/repo/org/apache/maven/plugins/mng-2926/0.1/mng-2926-0.1.pom
> ./core-it-suite/src/test/resources/mng-2926/repo/org/codehaus/mojo/mng-2926/0.1/mng-2926-0.1.pom
> ./core-it-suite/src/test/resources/mng-3203/src/main/java/org/apache/maven/it/mng3203/App.java
> ./core-it-suite/src/test/resources/mng-3203/src/main/java/org/apache/maven/it/mng3203/Diamond.java
> ./core-it-suite/src/test/resources/mng-3259/module1/pom.xml
> ./core-it-suite/src/test/resources/mng-3259/module1/src/main/java/mng/XStreamTestCase.java
> ./core-it-suite/src/test/resources/mng-3259/module2/pom.xml
> ./core-it-suite/src/test/resources/mng-3259/module2/src/main/java/mng/Module2.java
> ./core-it-suite/src/test/resources/mng-3259/module3/pom.xml
> ./core-it-suite/src/test/resources/mng-3259/module3/src/main/java/mng/Module3.java
> ./core-it-suite/src/test/resources/mng-3259/module3/src/test/java/mng/Module3TestUtil.java
> ./core-it-suite/src/test/resources/mng-3259/module4/pom.xml
> ./core-it-suite/src/test/resources/mng-3259/module4/src/main/java/mng/Module4.java
> ./core-it-suite/src/test/resources/mng-3259/module4/src/main/java/mng/Module4Bean.java
> ./core-it-suite/src/test/resources/mng-3259/module5/pom.xml
> ./core-it-suite/src/test/resources/mng-3259/module5/src/main/java/mng/Module5.java
> ./core-it-suite/src/test/resources/mng-3259/module5/src/test/java/mng/Module5Test.java
> ./core-it-suite/src/test/resources/mng-3259/parent/pom.xml
> ./core-it-suite/src/test/resources/mng-3372/dependency-tree/pom.xml
> ./core-it-suite/src/test/resources/mng-3506/mng-3506.1/src/main/java/org/apache/maven/its/mng3506/App.java
> ./core-it-suite/src/test/resources/mng-3506/mng-3506.1/src/test/java/org/apache/maven/its/mng3506/AppTest.java
> ./core-it-suite/src/test/resources/mng-3506/mng-3506.2/src/main/java/org/apache/maven/its/mng3506/App.java
> ./core-it-suite/src/test/resources/mng-3506/mng-3506.2/src/test/java/org/apache/maven/its/mng3506/AppTest.java
> ./core-it-suite/src/test/resources/mng-3652/test-plugin/pom.xml
> ./core-it-suite/src/test/resources/mng-3684/maven-mng3684-plugin/pom.xml
> ./core-it-suite/src/test/resources/mng-3693/maven-mng3693-plugin/pom.xml
> ./core-it-suite/src/test/resources/mng-3693/projects/app/pom.xml
> ./core-it-suite/src/test/resources/mng-3694/maven-mng3694-plugin/pom.xml
> ./core-it-suite/src/test/resources/mng-3694/maven-mng3694-plugin/src/main/java/plugin/MyMojo.java
> ./core-it-suite/src/test/resources/mng-3703/maven-mng3703-plugin/pom.xml
> ./core-it-suite/src/test/resources/mng-3704/maven-mng3704-plugin/pom.xml
> ./core-it-suite/src/test/resources/mng-3710/original-model/plugins/maven-mng3710-originalModel-plugin/pom.xml
> ./core-it-suite/src/test/resources/mng-3710/pom-inheritance/projects/middle/pom.xml
> ./core-it-suite/src/test/resources/mng-3716/projects/pom.xml
> ./core-it-suite/src/test/resources/mng-3723/maven-mng3723-plugin/pom.xml
> ./core-it-suite/src/test/resources/mng-3723/projects/pom.xml
> ./core-it-suite/src/test/resources/mng-3724/maven-mng3724-plugin/pom.xml
> ./core-it-suite/src/test/resources/mng-3743/plugins/maven-mng3743-report-plugin/pom.xml
> ./core-it-suite/src/test/resources/mng-3743/plugins/pom.xml
> ./core-it-suite/src/test/resources/mng-3814/plugin-a/pom.xml
>

[jira] [Updated] (MNG-7169) Update Guice dependency to 5.0.1



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

Michael Osipov updated MNG-7169:

Fix Version/s: waiting-for-feedback

> Update Guice dependency to 5.0.1
> 
>
> Key: MNG-7169
> URL: https://issues.apache.org/jira/browse/MNG-7169
> Project: Maven
>  Issue Type: Dependency upgrade
>Affects Versions: 3.8.1
>Reporter: Timm Fitschen
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Thank you for your work!
> I hope this is the correct issue tracker:
> With maven 3.8.1, I got a warning:
> {code}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by 
> com.google.inject.internal.cglib.core.$ReflectUtils$1 
> (file:/usr/share/maven/lib/guice.jar) to method 
> java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
> WARNING: Please consider reporting this to the maintainers of 
> com.google.inject.internal.cglib.core.$ReflectUtils$1
> WARNING: Use --illegal-access=warn to enable warnings of further illegal 
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {code}
> Aparently, maven-core has a guice-4.2.1 compile dependency. Please consider 
> updating to 5.0.1 which should solve the `illegal access` issue.
> See guice bug report: https://github.com/google/guice/issues/1133 
> and guice release notes: https://github.com/google/guice/wiki/Guice501



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-surefire] kriegaex commented on pull request #355: [SUREFIRE-1881] - Fix and extend integration test



kriegaex commented on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873560441


   According to the CI results, now `Surefire1881IT` is actually (and 
successfully for both cases) executed. So far, so good. Why in one case on 
MacOS `JUnit47ParallelIT.forcedShutdownVerifyingLogs` failed, I do not know, 
but I think I have seen it before. It looks like this test is flaky and should 
be fixed (in another PR).
   
   When looking at https://github.com/kriegaex/maven-surefire/actions, you see 
what happens in the back-ported tests, e.g. 
[here](https://github.com/kriegaex/maven-surefire/actions/runs/997851433). Of 
course, in the log there is no way to find out about the hanging processes 
which are never terminated, but for that you can look at my screenshot above or 
just run the test locally, keeping count of Java processes with a process 
manager.


-- 
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-7169) Update Guice dependency to 5.0.1



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

Sylwester Lachiewicz commented on MNG-7169:
---

Please also add information about environment, operating system and information 
if Maven was installed from our binary or from os distribution (output of `mvn 
-v` would be helpful)

> Update Guice dependency to 5.0.1
> 
>
> Key: MNG-7169
> URL: https://issues.apache.org/jira/browse/MNG-7169
> Project: Maven
>  Issue Type: Dependency upgrade
>Affects Versions: 3.8.1
>Reporter: Timm Fitschen
>Priority: Major
>
> Thank you for your work!
> I hope this is the correct issue tracker:
> With maven 3.8.1, I got a warning:
> {code}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by 
> com.google.inject.internal.cglib.core.$ReflectUtils$1 
> (file:/usr/share/maven/lib/guice.jar) to method 
> java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
> WARNING: Please consider reporting this to the maintainers of 
> com.google.inject.internal.cglib.core.$ReflectUtils$1
> WARNING: Use --illegal-access=warn to enable warnings of further illegal 
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {code}
> Aparently, maven-core has a guice-4.2.1 compile dependency. Please consider 
> updating to 5.0.1 which should solve the `illegal access` issue.
> See guice bug report: https://github.com/google/guice/issues/1133 
> and guice release notes: https://github.com/google/guice/wiki/Guice501



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-7169) Update Guice dependency to 5.0.1



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

Michael Osipov commented on MNG-7169:
-

Can you show how to reproduce the issue?

> Update Guice dependency to 5.0.1
> 
>
> Key: MNG-7169
> URL: https://issues.apache.org/jira/browse/MNG-7169
> Project: Maven
>  Issue Type: Dependency upgrade
>Affects Versions: 3.8.1
>Reporter: Timm Fitschen
>Priority: Major
>
> Thank you for your work!
> I hope this is the correct issue tracker:
> With maven 3.8.1, I got a warning:
> {code}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by 
> com.google.inject.internal.cglib.core.$ReflectUtils$1 
> (file:/usr/share/maven/lib/guice.jar) to method 
> java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
> WARNING: Please consider reporting this to the maintainers of 
> com.google.inject.internal.cglib.core.$ReflectUtils$1
> WARNING: Use --illegal-access=warn to enable warnings of further illegal 
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {code}
> Aparently, maven-core has a guice-4.2.1 compile dependency. Please consider 
> updating to 5.0.1 which should solve the `illegal access` issue.
> See guice bug report: https://github.com/google/guice/issues/1133 
> and guice release notes: https://github.com/google/guice/wiki/Guice501



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MNG-6836) Too Many Open Files for large projects



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

Michael Osipov updated MNG-6836:

Fix Version/s: waiting-for-feedback

> Too Many Open Files for large projects
> --
>
> Key: MNG-6836
> URL: https://issues.apache.org/jira/browse/MNG-6836
> Project: Maven
>  Issue Type: Bug
>  Components: Plugins and Lifecycle
>Affects Versions: 3.5.2, 3.5.3, 3.5.4, 3.6.0, 3.6.1, 3.6.2, 3.6.3
>Reporter: Cody Wayne Holmes
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> This issue seems to be that all plugins classloaders are created and then 
> cached, and plugins are internally creating classloaders that are not being 
> closed and therefore leaving open file handles to jar files waiting to be 
> finalized.
>  
> When a project gets big enough with enough modules and plugins than this 
> becomes a problem as the project will reach a large number of open jar files 
> by the time it completes and if the file system is not set up to allow the 
> standard ulimit to be exceeded, then this will cause build failures.
>  
> One plugin example that opens and does not close a URLClassloader is the 
> [maven-pmd-plugin|#L796]]. As you can see it calls the method to prepend the 
> classpath for the plugin to run. This method then [creates|#L196]] a 
> URLClassloader that is not closed and must be finalized.
>  
> With the deprecation of the finalizer and the knowledge that it is not a good 
> mechanism for closing system resources reliably, this also causes issues for 
> larger projects with a lot of modules and a slightly larger build time.
>  
> I am not sure what can be done about this issue in the maven lifecycle, but 
> just wanted to ask the question and find out if anyone else has seen similar 
> issues or knows of a way to resolve this open file handles problem. And 
> possibly find a way to limit the number of open file handles to the 
> downloaded artifacts.
>  
> Thanks.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-6836) Too Many Open Files for large projects



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

Michael Osipov commented on MNG-6836:
-

Can you provide some realworld numbers?

> Too Many Open Files for large projects
> --
>
> Key: MNG-6836
> URL: https://issues.apache.org/jira/browse/MNG-6836
> Project: Maven
>  Issue Type: Bug
>  Components: Plugins and Lifecycle
>Affects Versions: 3.5.2, 3.5.3, 3.5.4, 3.6.0, 3.6.1, 3.6.2, 3.6.3
>Reporter: Cody Wayne Holmes
>Priority: Major
>
> This issue seems to be that all plugins classloaders are created and then 
> cached, and plugins are internally creating classloaders that are not being 
> closed and therefore leaving open file handles to jar files waiting to be 
> finalized.
>  
> When a project gets big enough with enough modules and plugins than this 
> becomes a problem as the project will reach a large number of open jar files 
> by the time it completes and if the file system is not set up to allow the 
> standard ulimit to be exceeded, then this will cause build failures.
>  
> One plugin example that opens and does not close a URLClassloader is the 
> [maven-pmd-plugin|#L796]]. As you can see it calls the method to prepend the 
> classpath for the plugin to run. This method then [creates|#L196]] a 
> URLClassloader that is not closed and must be finalized.
>  
> With the deprecation of the finalizer and the knowledge that it is not a good 
> mechanism for closing system resources reliably, this also causes issues for 
> larger projects with a lot of modules and a slightly larger build time.
>  
> I am not sure what can be done about this issue in the maven lifecycle, but 
> just wanted to ask the question and find out if anyone else has seen similar 
> issues or knows of a way to resolve this open file handles problem. And 
> possibly find a way to limit the number of open file handles to the 
> downloaded artifacts.
>  
> Thanks.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (MNG-6612) Ability to set repository of dependency



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

Michael Osipov closed MNG-6612.
---
Resolution: Duplicate

This can be implemented with MNG-6763.

> Ability to set repository of dependency
> ---
>
> Key: MNG-6612
> URL: https://issues.apache.org/jira/browse/MNG-6612
> Project: Maven
>  Issue Type: New Feature
>  Components: Dependencies
>Reporter: Max Lee
>Priority: Minor
>  Labels: Repository, dependency
>
> In a setup where you specify multiple different repositories for your project 
> it would be a useful to be able to specify which repository contains which 
> dependency in the pom and not resolve such dependencies from the general 
> repositories but only the ones defined for the dependency.
> E.g. in cases where you don't want other dependencies to get resolve in 
> certain repositories because they contain broken versions or when you simply 
> want to stop the potential privacy/security issues that leaking dependencies 
> to another repository that doesn't even include the dependency could 
> introduce. (Theoretically an ignored/skip-repositories setting could also 
> solve this issue) Another application of this feature could be to define 
> different update or checksum check setting for different artifacts that would 
> use the same repository.
> This could theoretically be setup using the repository name:
>  
> {code:java}
> 
> id.group
> artifact-id
> version-string
> 
> repository-id
> 
> 
> {code}
> or by allowing to directly set the repository-settings in the dependency and 
> not on the outer scope (this would allow for a wider range of applications by 
> allowing different repository settings per artifact but require a larger 
> config for simply setting the repository of an artifact)
>  
> {code:java}
> 
> id.group
> artifact-id
> version-string
> 
> 
> repository-id
> https://repo.example.com/
> 
> 
> 
> {code}
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (MNG-7100) Upgrade maven-shared-utils dependency from 3.2.1 -> 3.3.3 in maven-core



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

Michael Osipov closed MNG-7100.
---
Resolution: Duplicate

> Upgrade maven-shared-utils dependency from 3.2.1 -> 3.3.3 in maven-core
> ---
>
> Key: MNG-7100
> URL: https://issues.apache.org/jira/browse/MNG-7100
> Project: Maven
>  Issue Type: Dependency upgrade
>Affects Versions: 3.6.3
>Reporter: Tomasz Zasada
>Priority: Major
>
> maven-shared-utils 3.2.1 has known vulnerabilities: 
> [https://snyk.io/vuln/SNYK-JAVA-ORGAPACHEMAVENSHARED-570592.]
> Please upgrade maven-core to use 3.3.3 version of maven-shared-utils



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MNG-7075) mvnDebug --version should only show version info



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

Michael Osipov updated MNG-7075:

Fix Version/s: wontfix-candidate
   waiting-for-feedback

> mvnDebug --version should only show version info
> 
>
> Key: MNG-7075
> URL: https://issues.apache.org/jira/browse/MNG-7075
> Project: Maven
>  Issue Type: New Feature
>  Components: Bootstrap  Build
>Reporter: Paul Hammant
>Priority: Minor
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> {{$ mvnDebug --version }}{{Preparing to execute Maven in debug 
> mode}}{{Listening for transport dt_socket at address: 8000}}
> Should really only spit out the same info as:
> {{$ mvn --version }}{{Apache Maven 3.6.3 
> (cecedd343002696d0abb50b32b541b8a6ba2883f)}}{{Maven home: 
> /usr/local/Cellar/maven/3.6.3_1/libexec}}{{Java version: 11.0.9, vendor: 
> Oracle Corporation, runtime: 
> /Library/Java/JavaVirtualMachines/jdk-11.0.9.jdk/Contents/Home}}{{Default 
> locale: en_US, platform encoding: UTF-8}}{{OS name: "mac os x", version: 
> "10.14.6", arch: "x86_64", family: "mac"}}
> In other words {{mvnDebug }}should *not* listen on the remote debugger port 
> in this {{ --version}}{{ usage}}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-7121) better support for multiple JDK



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

Michael Osipov commented on MNG-7121:
-

I have moved this to wontfix-candidate for now becuase no one of us will work 
on this. I if no traction will happen in a couple of months this will be closed.

> better support for multiple JDK
> ---
>
> Key: MNG-7121
> URL: https://issues.apache.org/jira/browse/MNG-7121
> Project: Maven
>  Issue Type: New Feature
>  Components: core
>Reporter: Pablo Grisafi
>Priority: Major
> Fix For: wontfix-candidate
>
>
> Java evolves at a much faster pace now. In the compay I work for we have 
> projects on Java 6 (sadly yes), 8, 11 and 15.
>  
> The toolchains plugin helps, but it involves manually editing an  xml file, 
> and in my experience people tend to forget about it.
>  
> I think a better user experiense would be a ~/.m2/jdks folder, with one 
> subfolder per jdk, a little like sdkman does it.
> Maven could even automaticlly download the one you need for a specific 
> project if it is not already present, like it does with any dependency. It 
> will be more portable and less manual work. Dependency handling and jdk 
> handling will be managed be maven in a consistent way, cloning a project from 
> github will be way more straightforward.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MNG-7121) better support for multiple JDK



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

Michael Osipov updated MNG-7121:

Fix Version/s: wontfix-candidate

> better support for multiple JDK
> ---
>
> Key: MNG-7121
> URL: https://issues.apache.org/jira/browse/MNG-7121
> Project: Maven
>  Issue Type: New Feature
>  Components: core
>Reporter: Pablo Grisafi
>Priority: Major
> Fix For: wontfix-candidate
>
>
> Java evolves at a much faster pace now. In the compay I work for we have 
> projects on Java 6 (sadly yes), 8, 11 and 15.
>  
> The toolchains plugin helps, but it involves manually editing an  xml file, 
> and in my experience people tend to forget about it.
>  
> I think a better user experiense would be a ~/.m2/jdks folder, with one 
> subfolder per jdk, a little like sdkman does it.
> Maven could even automaticlly download the one you need for a specific 
> project if it is not already present, like it does with any dependency. It 
> will be more portable and less manual work. Dependency handling and jdk 
> handling will be managed be maven in a consistent way, cloning a project from 
> github will be way more straightforward.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (MNG-7168) maven-shared-utils package is vulnerable to Command Injection



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

Michael Osipov closed MNG-7168.
---
Resolution: Done

No directly a Maven problem. Dependency has been already upgraded.

> maven-shared-utils package is vulnerable to Command Injection
> -
>
> Key: MNG-7168
> URL: https://issues.apache.org/jira/browse/MNG-7168
> Project: Maven
>  Issue Type: Bug
>Reporter: Dwayne E Culbertson
>Priority: Major
>  Labels: Security
>
>  
> Project:[https://github.com/apache/maven-shared-utils/pull/40]
>  Project:https://issues.apache.org/jira/browse/MSHARED-297
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-7096) Maven master and m-shade-p 3.2.1 hangs forever



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

Michael Osipov commented on MNG-7096:
-

[~cstamas], can you verify again?

> Maven master and m-shade-p 3.2.1 hangs forever
> --
>
> Key: MNG-7096
> URL: https://issues.apache.org/jira/browse/MNG-7096
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 4.0.x-candidate
>Reporter: Tamás Cservenák
>Priority: Critical
>
> A fairly huge build, works okay with Maven 3.6.3, but with Maven 
> 4.0.0-alpha-1-SNAPSHOT (ab20190a1a9fecdc8f85b40e8d03d806f3da4fc6) hangs 
> forever at maven-shade-plugin:3.2.1 shade:shade goal.
> Env
> {noformat}
> $ ~/bin/maven/apache-maven-4.0.0-alpha-1-SNAPSHOT/bin/mvn -v
> Apache Maven 4.0.0-alpha-1-SNAPSHOT (ab20190a1a9fecdc8f85b40e8d03d806f3da4fc6)
> Maven home: /home/cstamas/bin/maven/apache-maven-4.0.0-alpha-1-SNAPSHOT
> Java version: 1.8.0_282, vendor: AdoptOpenJDK, runtime: 
> /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.8.0-43-generic", arch: "amd64", family: "unix"
> {noformat}
> JStack shows this:
> {{"main" #1 prio=5 os_prio=0 tid=0x7fa84000b000 nid=0x9846 runnable 
> [0x7fa84634d000]"main" #1 prio=5 os_prio=0 tid=0x7fa84000b000 
> nid=0x9846 runnable [0x7fa84634d000]   java.lang.Thread.State: RUNNABLE 
> at 
> org.jdom2.output.support.AbstractFormattedWalker.next(AbstractFormattedWalker.java:465)
>  at 
> org.jdom2.output.support.AbstractXMLOutputProcessor.printContent(AbstractXMLOutputProcessor.java:925)
>  at 
> org.jdom2.output.support.AbstractXMLOutputProcessor.printElement(AbstractXMLOutputProcessor.java:868)
>  at 
> org.jdom2.output.support.AbstractXMLOutputProcessor.printContent(AbstractXMLOutputProcessor.java:946)
>  at 
> org.jdom2.output.support.AbstractXMLOutputProcessor.printElement(AbstractXMLOutputProcessor.java:868)
>  at 
> org.jdom2.output.support.AbstractXMLOutputProcessor.printContent(AbstractXMLOutputProcessor.java:946)
>  at 
> org.jdom2.output.support.AbstractXMLOutputProcessor.printElement(AbstractXMLOutputProcessor.java:868)
>  at 
> org.jdom2.output.support.AbstractXMLOutputProcessor.printContent(AbstractXMLOutputProcessor.java:946)
>  at 
> org.jdom2.output.support.AbstractXMLOutputProcessor.printElement(AbstractXMLOutputProcessor.java:868)
>  at 
> org.jdom2.output.support.AbstractXMLOutputProcessor.printContent(AbstractXMLOutputProcessor.java:946)
>  at 
> org.jdom2.output.support.AbstractXMLOutputProcessor.printElement(AbstractXMLOutputProcessor.java:868)
>  at 
> org.jdom2.output.support.AbstractXMLOutputProcessor.printDocument(AbstractXMLOutputProcessor.java:533)
>  at 
> org.jdom2.output.support.AbstractXMLOutputProcessor.process(AbstractXMLOutputProcessor.java:191)
>  at org.jdom2.output.XMLOutputter.output(XMLOutputter.java:822) at 
> org.apache.maven.plugins.shade.pom.MavenJDOMWriter.write(MavenJDOMWriter.java:2159)
>  at org.apache.maven.plugins.shade.pom.PomWriter.write(PomWriter.java:75) at 
> org.apache.maven.plugins.shade.mojo.ShadeMojo.rewriteDependencyReducedPomIfWeHaveReduction(ShadeMojo.java:1049)
>  at 
> org.apache.maven.plugins.shade.mojo.ShadeMojo.createDependencyReducedPom(ShadeMojo.java:978)
>  at org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:538) 
> at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:136)
>  at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
>  at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:159)
>  at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:151)
>  at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:115)
>  at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:79)
>  at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:64)
>  at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:131)
>  at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:338) at 
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:217) at 
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:130) at 
> org.apache.maven.cli.MavenCli.execute(MavenCli.java:980) at 
> org.apache.maven.cli.MavenCli.doMain(MavenCli.java:294) at 
> org.apache.maven.cli.MavenCli.main(MavenCli.java:198) at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at

[jira] [Commented] (MSITE-828) Jdk 1.8 required



[ 
https://issues.apache.org/jira/browse/MSITE-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374218#comment-17374218
 ] 

Sylwester Lachiewicz commented on MSITE-828:


Is now the right time to upgrade to Java 8 for this plugin?

> Jdk 1.8 required
> 
>
> Key: MSITE-828
> URL: https://issues.apache.org/jira/browse/MSITE-828
> Project: Maven Site Plugin
>  Issue Type: Task
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.10.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MNG-7056) Replace tabs in IT files



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

Michael Osipov updated MNG-7056:

Description: 
These files:
{noformat}
$ grep -rl '^I' . | sort -u | grep -v -e '.jar$' -e Makefile -e '.war$'
./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3642DynamicResourcesTest.java
./core-it-suite/src/test/resources/bootstrap/group-11/pom.xml
./core-it-suite/src/test/resources/bootstrap/group-12/pom.xml
./core-it-suite/src/test/resources/it0038/pom.xml
./core-it-suite/src/test/resources/mng-0612/project/pom.xml
./core-it-suite/src/test/resources/mng-0773/settings.xml
./core-it-suite/src/test/resources/mng-2196/pom.xml
./core-it-suite/src/test/resources/mng-2289/issue/src/main/java/mng/Issue2289.java
./core-it-suite/src/test/resources/mng-2305/keystore
./core-it-suite/src/test/resources/mng-2771/project/pom.xml
./core-it-suite/src/test/resources/mng-2926/repo/org/apache/maven/its/mng2926/mng-2926/0.1/mng-2926-0.1.pom
./core-it-suite/src/test/resources/mng-2926/repo/org/apache/maven/plugins/mng-2926/0.1/mng-2926-0.1.pom
./core-it-suite/src/test/resources/mng-2926/repo/org/codehaus/mojo/mng-2926/0.1/mng-2926-0.1.pom
./core-it-suite/src/test/resources/mng-3203/src/main/java/org/apache/maven/it/mng3203/App.java
./core-it-suite/src/test/resources/mng-3203/src/main/java/org/apache/maven/it/mng3203/Diamond.java
./core-it-suite/src/test/resources/mng-3259/module1/pom.xml
./core-it-suite/src/test/resources/mng-3259/module1/src/main/java/mng/XStreamTestCase.java
./core-it-suite/src/test/resources/mng-3259/module2/pom.xml
./core-it-suite/src/test/resources/mng-3259/module2/src/main/java/mng/Module2.java
./core-it-suite/src/test/resources/mng-3259/module3/pom.xml
./core-it-suite/src/test/resources/mng-3259/module3/src/main/java/mng/Module3.java
./core-it-suite/src/test/resources/mng-3259/module3/src/test/java/mng/Module3TestUtil.java
./core-it-suite/src/test/resources/mng-3259/module4/pom.xml
./core-it-suite/src/test/resources/mng-3259/module4/src/main/java/mng/Module4.java
./core-it-suite/src/test/resources/mng-3259/module4/src/main/java/mng/Module4Bean.java
./core-it-suite/src/test/resources/mng-3259/module5/pom.xml
./core-it-suite/src/test/resources/mng-3259/module5/src/main/java/mng/Module5.java
./core-it-suite/src/test/resources/mng-3259/module5/src/test/java/mng/Module5Test.java
./core-it-suite/src/test/resources/mng-3259/parent/pom.xml
./core-it-suite/src/test/resources/mng-3372/dependency-tree/pom.xml
./core-it-suite/src/test/resources/mng-3506/mng-3506.1/src/main/java/org/apache/maven/its/mng3506/App.java
./core-it-suite/src/test/resources/mng-3506/mng-3506.1/src/test/java/org/apache/maven/its/mng3506/AppTest.java
./core-it-suite/src/test/resources/mng-3506/mng-3506.2/src/main/java/org/apache/maven/its/mng3506/App.java
./core-it-suite/src/test/resources/mng-3506/mng-3506.2/src/test/java/org/apache/maven/its/mng3506/AppTest.java
./core-it-suite/src/test/resources/mng-3652/test-plugin/pom.xml
./core-it-suite/src/test/resources/mng-3684/maven-mng3684-plugin/pom.xml
./core-it-suite/src/test/resources/mng-3693/maven-mng3693-plugin/pom.xml
./core-it-suite/src/test/resources/mng-3693/projects/app/pom.xml
./core-it-suite/src/test/resources/mng-3694/maven-mng3694-plugin/pom.xml
./core-it-suite/src/test/resources/mng-3694/maven-mng3694-plugin/src/main/java/plugin/MyMojo.java
./core-it-suite/src/test/resources/mng-3703/maven-mng3703-plugin/pom.xml
./core-it-suite/src/test/resources/mng-3704/maven-mng3704-plugin/pom.xml
./core-it-suite/src/test/resources/mng-3710/original-model/plugins/maven-mng3710-originalModel-plugin/pom.xml
./core-it-suite/src/test/resources/mng-3710/pom-inheritance/projects/middle/pom.xml
./core-it-suite/src/test/resources/mng-3716/projects/pom.xml
./core-it-suite/src/test/resources/mng-3723/maven-mng3723-plugin/pom.xml
./core-it-suite/src/test/resources/mng-3723/projects/pom.xml
./core-it-suite/src/test/resources/mng-3724/maven-mng3724-plugin/pom.xml
./core-it-suite/src/test/resources/mng-3743/plugins/maven-mng3743-report-plugin/pom.xml
./core-it-suite/src/test/resources/mng-3743/plugins/pom.xml
./core-it-suite/src/test/resources/mng-3814/plugin-a/pom.xml
./core-it-suite/src/test/resources/mng-4148/remote-repository/org/apache/maven/its/mng4148/module/1.0.0/module-1.0.0.pom
./core-it-suite/src/test/resources/mng-4270/src/main/java/org/apache/maven/its/mng3506/App.java
./core-it-suite/src/test/resources/mng-4270/src/test/java/org/apache/maven/its/mng3506/AppTest.java
./core-it-suite/src/test/resources/mng-4347/src/main/java/org/apache/maven/it/mng4347/App.java
./core-it-suite/src/test/resources/mng-4428/keystore
./core-it-suite/src/test/resources/mng-4660-outdated-packaged-artifact/module-a/pom.xml
./core-it-suite/src/test/resources/mng-4660-outdated-packaged-artifact/module-b/pom.xml
./core-it-suite/src/test/resources/mng-4660-resume-from/module-a/pom.xml

[jira] [Closed] (MCOMPILER-455) preparePaths does not take toolchain into account when parsing module-info.class



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

Sylwester Lachiewicz closed MCOMPILER-455.
--
Resolution: Fixed

Fixed with plexus-java upgrade to 1.0.7 in 
[4cb16a968db75488becef47b4f56de3a59d9e381|https://gitbox.apache.org/repos/asf?p=maven-compiler-plugin.git;a=commit;h=4cb16a968db75488becef47b4f56de3a59d9e381]
 

> preparePaths does not take toolchain into account when parsing 
> module-info.class
> 
>
> Key: MCOMPILER-455
> URL: https://issues.apache.org/jira/browse/MCOMPILER-455
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Benjamin Marwell
>Assignee: Sylwester Lachiewicz
>Priority: Blocker
>  Labels: modularization, module, modules, toolchain, toolchains
> Fix For: 3.9.0
>
>
> If you re-compile modules (e.g. via second execution of mvn compile), the 
> CompileMojo tries to read existing module descriptors. If you used toolchains 
> to compile those, this process will fail:
>  
> {code:java}
> Caused by: java.lang.module.InvalidModuleDescriptorException: Unsupported 
> major.minor version 59.0
> at jdk.internal.module.ModuleInfo.invalidModuleDescriptor 
> (ModuleInfo.java:1091)
> at jdk.internal.module.ModuleInfo.doRead (ModuleInfo.java:195)
> at jdk.internal.module.ModuleInfo.read (ModuleInfo.java:131)
> at java.lang.module.ModuleDescriptor.read (ModuleDescriptor.java:2487)
> at org.codehaus.plexus.languages.java.jpms.BinaryModuleInfoParser.parse 
> (BinaryModuleInfoParser.java:35)
> at 
> org.codehaus.plexus.languages.java.jpms.AbstractBinaryModuleInfoParser.getModuleDescriptor
>  (AbstractBinaryModuleInfoParser.java:45)
> at org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePaths 
> (LocationManager.java:127)
> at org.apache.maven.plugin.compiler.CompilerMojo.preparePaths 
> (CompilerMojo.java:238)
> at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute 
> (AbstractCompilerMojo.java:792)
> at org.apache.maven.plugin.compiler.CompilerMojo.execute 
> (CompilerMojo.java:187)
> {code}
> Test project: https://github.com/torakiki/testme
> Reproduce:
> * git clone https://github.com/torakiki/testme.git
> * cd testme
> * mvn compile
> * mvn compile



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MNG-7056) Replace tabs in IT files



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

Michael Osipov updated MNG-7056:

Description: 
These files:
{noformat}
$ grep -rl '^I' . | sort -u | grep -v -e '.jar$' -e Makefile -e '.war$'
./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3642DynamicResourcesTest.java
./core-it-suite/src/test/resources/bootstrap/group-11/pom.xml
./core-it-suite/src/test/resources/it0038/pom.xml
./core-it-suite/src/test/resources/mng-0612/project/pom.xml
./core-it-suite/src/test/resources/mng-0773/settings.xml
./core-it-suite/src/test/resources/mng-2196/pom.xml
./core-it-suite/src/test/resources/mng-2289/issue/src/main/java/mng/Issue2289.java
./core-it-suite/src/test/resources/mng-2305/keystore
./core-it-suite/src/test/resources/mng-2771/project/pom.xml
./core-it-suite/src/test/resources/mng-2926/repo/org/apache/maven/its/mng2926/mng-2926/0.1/mng-2926-0.1.pom
./core-it-suite/src/test/resources/mng-2926/repo/org/apache/maven/plugins/mng-2926/0.1/mng-2926-0.1.pom
./core-it-suite/src/test/resources/mng-2926/repo/org/codehaus/mojo/mng-2926/0.1/mng-2926-0.1.pom
./core-it-suite/src/test/resources/mng-3203/src/main/java/org/apache/maven/it/mng3203/App.java
./core-it-suite/src/test/resources/mng-3203/src/main/java/org/apache/maven/it/mng3203/Diamond.java
./core-it-suite/src/test/resources/mng-3259/module1/pom.xml
./core-it-suite/src/test/resources/mng-3259/module1/src/main/java/mng/XStreamTestCase.java
./core-it-suite/src/test/resources/mng-3259/module2/pom.xml
./core-it-suite/src/test/resources/mng-3259/module2/src/main/java/mng/Module2.java
./core-it-suite/src/test/resources/mng-3259/module3/pom.xml
./core-it-suite/src/test/resources/mng-3259/module3/src/main/java/mng/Module3.java
./core-it-suite/src/test/resources/mng-3259/module3/src/test/java/mng/Module3TestUtil.java
./core-it-suite/src/test/resources/mng-3259/module4/pom.xml
./core-it-suite/src/test/resources/mng-3259/module4/src/main/java/mng/Module4.java
./core-it-suite/src/test/resources/mng-3259/module4/src/main/java/mng/Module4Bean.java
./core-it-suite/src/test/resources/mng-3259/module5/pom.xml
./core-it-suite/src/test/resources/mng-3259/module5/src/main/java/mng/Module5.java
./core-it-suite/src/test/resources/mng-3259/module5/src/test/java/mng/Module5Test.java
./core-it-suite/src/test/resources/mng-3259/parent/pom.xml
./core-it-suite/src/test/resources/mng-3372/dependency-tree/pom.xml
./core-it-suite/src/test/resources/mng-3506/mng-3506.1/src/main/java/org/apache/maven/its/mng3506/App.java
./core-it-suite/src/test/resources/mng-3506/mng-3506.1/src/test/java/org/apache/maven/its/mng3506/AppTest.java
./core-it-suite/src/test/resources/mng-3506/mng-3506.2/src/main/java/org/apache/maven/its/mng3506/App.java
./core-it-suite/src/test/resources/mng-3506/mng-3506.2/src/test/java/org/apache/maven/its/mng3506/AppTest.java
./core-it-suite/src/test/resources/mng-3652/test-plugin/pom.xml
./core-it-suite/src/test/resources/mng-3684/maven-mng3684-plugin/pom.xml
./core-it-suite/src/test/resources/mng-3693/maven-mng3693-plugin/pom.xml
./core-it-suite/src/test/resources/mng-3693/projects/app/pom.xml
./core-it-suite/src/test/resources/mng-3694/maven-mng3694-plugin/pom.xml
./core-it-suite/src/test/resources/mng-3694/maven-mng3694-plugin/src/main/java/plugin/MyMojo.java
./core-it-suite/src/test/resources/mng-3703/maven-mng3703-plugin/pom.xml
./core-it-suite/src/test/resources/mng-3704/maven-mng3704-plugin/pom.xml
./core-it-suite/src/test/resources/mng-3710/original-model/plugins/maven-mng3710-originalModel-plugin/pom.xml
./core-it-suite/src/test/resources/mng-3710/pom-inheritance/projects/middle/pom.xml
./core-it-suite/src/test/resources/mng-3716/projects/pom.xml
./core-it-suite/src/test/resources/mng-3723/maven-mng3723-plugin/pom.xml
./core-it-suite/src/test/resources/mng-3723/projects/pom.xml
./core-it-suite/src/test/resources/mng-3724/maven-mng3724-plugin/pom.xml
./core-it-suite/src/test/resources/mng-3743/plugins/maven-mng3743-report-plugin/pom.xml
./core-it-suite/src/test/resources/mng-3743/plugins/pom.xml
./core-it-suite/src/test/resources/mng-3814/plugin-a/pom.xml
./core-it-suite/src/test/resources/mng-4148/remote-repository/org/apache/maven/its/mng4148/module/1.0.0/module-1.0.0.pom
./core-it-suite/src/test/resources/mng-4270/src/main/java/org/apache/maven/its/mng3506/App.java
./core-it-suite/src/test/resources/mng-4270/src/test/java/org/apache/maven/its/mng3506/AppTest.java
./core-it-suite/src/test/resources/mng-4347/src/main/java/org/apache/maven/it/mng4347/App.java
./core-it-suite/src/test/resources/mng-4428/keystore
./core-it-suite/src/test/resources/mng-4660-outdated-packaged-artifact/module-a/pom.xml
./core-it-suite/src/test/resources/mng-4660-outdated-packaged-artifact/module-b/pom.xml
./core-it-suite/src/test/resources/mng-4660-resume-from/module-a/pom.xml
./core-it-suite/src/test/resources/mng-4660-resume-from/module-b/pom.xml

[jira] [Updated] (MCOMPILER-455) preparePaths does not take toolchain into account when parsing module-info.class



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

Sylwester Lachiewicz updated MCOMPILER-455:
---
Fix Version/s: 3.9.0

> preparePaths does not take toolchain into account when parsing 
> module-info.class
> 
>
> Key: MCOMPILER-455
> URL: https://issues.apache.org/jira/browse/MCOMPILER-455
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Benjamin Marwell
>Priority: Blocker
>  Labels: modularization, module, modules, toolchain, toolchains
> Fix For: 3.9.0
>
>
> If you re-compile modules (e.g. via second execution of mvn compile), the 
> CompileMojo tries to read existing module descriptors. If you used toolchains 
> to compile those, this process will fail:
>  
> {code:java}
> Caused by: java.lang.module.InvalidModuleDescriptorException: Unsupported 
> major.minor version 59.0
> at jdk.internal.module.ModuleInfo.invalidModuleDescriptor 
> (ModuleInfo.java:1091)
> at jdk.internal.module.ModuleInfo.doRead (ModuleInfo.java:195)
> at jdk.internal.module.ModuleInfo.read (ModuleInfo.java:131)
> at java.lang.module.ModuleDescriptor.read (ModuleDescriptor.java:2487)
> at org.codehaus.plexus.languages.java.jpms.BinaryModuleInfoParser.parse 
> (BinaryModuleInfoParser.java:35)
> at 
> org.codehaus.plexus.languages.java.jpms.AbstractBinaryModuleInfoParser.getModuleDescriptor
>  (AbstractBinaryModuleInfoParser.java:45)
> at org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePaths 
> (LocationManager.java:127)
> at org.apache.maven.plugin.compiler.CompilerMojo.preparePaths 
> (CompilerMojo.java:238)
> at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute 
> (AbstractCompilerMojo.java:792)
> at org.apache.maven.plugin.compiler.CompilerMojo.execute 
> (CompilerMojo.java:187)
> {code}
> Test project: https://github.com/torakiki/testme
> Reproduce:
> * git clone https://github.com/torakiki/testme.git
> * cd testme
> * mvn compile
> * mvn compile



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (MCOMPILER-455) preparePaths does not take toolchain into account when parsing module-info.class



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

Sylwester Lachiewicz reassigned MCOMPILER-455:
--

Assignee: Sylwester Lachiewicz

> preparePaths does not take toolchain into account when parsing 
> module-info.class
> 
>
> Key: MCOMPILER-455
> URL: https://issues.apache.org/jira/browse/MCOMPILER-455
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Benjamin Marwell
>Assignee: Sylwester Lachiewicz
>Priority: Blocker
>  Labels: modularization, module, modules, toolchain, toolchains
> Fix For: 3.9.0
>
>
> If you re-compile modules (e.g. via second execution of mvn compile), the 
> CompileMojo tries to read existing module descriptors. If you used toolchains 
> to compile those, this process will fail:
>  
> {code:java}
> Caused by: java.lang.module.InvalidModuleDescriptorException: Unsupported 
> major.minor version 59.0
> at jdk.internal.module.ModuleInfo.invalidModuleDescriptor 
> (ModuleInfo.java:1091)
> at jdk.internal.module.ModuleInfo.doRead (ModuleInfo.java:195)
> at jdk.internal.module.ModuleInfo.read (ModuleInfo.java:131)
> at java.lang.module.ModuleDescriptor.read (ModuleDescriptor.java:2487)
> at org.codehaus.plexus.languages.java.jpms.BinaryModuleInfoParser.parse 
> (BinaryModuleInfoParser.java:35)
> at 
> org.codehaus.plexus.languages.java.jpms.AbstractBinaryModuleInfoParser.getModuleDescriptor
>  (AbstractBinaryModuleInfoParser.java:45)
> at org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePaths 
> (LocationManager.java:127)
> at org.apache.maven.plugin.compiler.CompilerMojo.preparePaths 
> (CompilerMojo.java:238)
> at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute 
> (AbstractCompilerMojo.java:792)
> at org.apache.maven.plugin.compiler.CompilerMojo.execute 
> (CompilerMojo.java:187)
> {code}
> Test project: https://github.com/torakiki/testme
> Reproduce:
> * git clone https://github.com/torakiki/testme.git
> * cd testme
> * mvn compile
> * mvn compile



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1926) Console logs should be synchronized



[ 
https://issues.apache.org/jira/browse/SUREFIRE-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374214#comment-17374214
 ] 

Michael Osipov commented on SUREFIRE-1926:
--

With SLF4J or sysout?

> Console logs should be synchronized
> ---
>
> Key: SUREFIRE-1926
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1926
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-compiler-plugin] slachiewicz closed pull request #38: update and specify dependencies



slachiewicz closed pull request #38:
URL: https://github.com/apache/maven-compiler-plugin/pull/38


   


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

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

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

[GitHub] [maven-compiler-plugin] asfgit closed pull request #58: Bump mockito-core from 2.28.2 to 3.11.2



asfgit closed pull request #58:
URL: https://github.com/apache/maven-compiler-plugin/pull/58


   


-- 
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-compiler-plugin] dependabot[bot] commented on pull request #58: Bump mockito-core from 2.28.2 to 3.11.2



dependabot[bot] commented on pull request #58:
URL: 
https://github.com/apache/maven-compiler-plugin/pull/58#issuecomment-873538066


   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-compiler-plugin] slachiewicz merged pull request #55: Bump actions/cache from 2.1.5 to 2.1.6



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


   


-- 
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-javadoc-plugin] slachiewicz merged pull request #81: Bump actions/cache from 2.1.5 to 2.1.6



slachiewicz merged pull request #81:
URL: https://github.com/apache/maven-javadoc-plugin/pull/81


   


-- 
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] slachiewicz commented on pull request #63: Bump mockito-core from 3.10.0 to 3.11.2



slachiewicz commented on pull request #63:
URL: https://github.com/apache/maven-jlink-plugin/pull/63#issuecomment-873537234


   @dependabot recreate


-- 
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] slachiewicz merged pull request #59: Bump commons-io from 2.9.0 to 2.10.0



slachiewicz merged pull request #59:
URL: https://github.com/apache/maven-jlink-plugin/pull/59


   


-- 
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] slachiewicz merged pull request #62: Bump assertj-core from 3.19.0 to 3.20.2



slachiewicz merged pull request #62:
URL: https://github.com/apache/maven-jlink-plugin/pull/62


   


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

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

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

[jira] [Comment Edited] (ARCHETYPE-584) Resulting root pom.xml from archetype generation has additional newlines with JDK11

2021-07-04 Thread Ruwen Reddig (Jira)



[ 
https://issues.apache.org/jira/browse/ARCHETYPE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374207#comment-17374207
 ] 

Ruwen Reddig edited comment on ARCHETYPE-584 at 7/4/21, 6:54 AM:
-

[~elharo] I googled the problem a bit and [this stackoverflow 
answer|https://stackoverflow.com/a/58481951] provides an explanation that makes 
sense and also fits the expected timeline (change introduced in JDK 9).

 

The change in {{ToStream.java}} that is mentioned on SO, can be found here: 
[https://github.com/openjdk/jdk/commit/1619ba484211c6f1b93fb13e22b507faa5e9d41b]


was (Author: newur):
[~elharo] I googled the problem a bit and [this stackoverflow 
answer|https://stackoverflow.com/a/58481951] provides an explanation that makes 
sense and also fits the expected timeline (change introduced in JDK 9).

 

The change in `ToStream.java` that is mentioned on SO, can be found here: 
[https://github.com/openjdk/jdk/commit/1619ba484211c6f1b93fb13e22b507faa5e9d41b]

> Resulting root pom.xml from archetype generation has additional newlines with 
> JDK11
> ---
>
> Key: ARCHETYPE-584
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-584
> Project: Maven Archetype
>  Issue Type: Bug
>  Components: Archetypes
>Affects Versions: 3.1.1, 3.1.2
>Reporter: Andre Prata
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This issue does not apply to version 3.1.0, it was introduced in version 
> 3.1.1.
>  
> In our project, we have the default configuration of the root pom.xml that 
> contains lines such as this:
> {code:java}
> 
> 11
> Greenwich.RELEASE
> 
> {code}
> These lines are still in good shape when added to the jar artifact. However, 
> upon generating the project from the archetype, we get the following (note 
> also the whitespace on the blank lines hinting at some indentation attempts, 
> not just the unexpected line breaks)
> {code:java}
> 
>   
>   
>   11
>   
>   
>   Greenwich.RELEASE
>   
> 
>   
> {code}
> This issue does *not* occur in in child module pom.xml files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (ARCHETYPE-584) Resulting root pom.xml from archetype generation has additional newlines with JDK11

2021-07-04 Thread Ruwen Reddig (Jira)



[ 
https://issues.apache.org/jira/browse/ARCHETYPE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374207#comment-17374207
 ] 

Ruwen Reddig edited comment on ARCHETYPE-584 at 7/4/21, 6:52 AM:
-

[~elharo] I googled the problem a bit and [this stackoverflow 
answer|https://stackoverflow.com/a/58481951] provides an explanation that makes 
sense and also fits the expected timeline (change introduced in JDK 9).

 

The change in `ToStream.java` that is mentioned on SO, can be found here: 
[https://github.com/openjdk/jdk/commit/1619ba484211c6f1b93fb13e22b507faa5e9d41b]


was (Author: newur):
[~elharo] googled the problem a bit and [this stackoverflow 
answer|https://stackoverflow.com/a/58481951] provides an explanation that makes 
sense and also fits the expected timeline (change introduced in JDK 9).

 

The change in `ToStream.java` that is mentioned on SO, can be found here: 
https://github.com/openjdk/jdk/commit/1619ba484211c6f1b93fb13e22b507faa5e9d41b

> Resulting root pom.xml from archetype generation has additional newlines with 
> JDK11
> ---
>
> Key: ARCHETYPE-584
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-584
> Project: Maven Archetype
>  Issue Type: Bug
>  Components: Archetypes
>Affects Versions: 3.1.1, 3.1.2
>Reporter: Andre Prata
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This issue does not apply to version 3.1.0, it was introduced in version 
> 3.1.1.
>  
> In our project, we have the default configuration of the root pom.xml that 
> contains lines such as this:
> {code:java}
> 
> 11
> Greenwich.RELEASE
> 
> {code}
> These lines are still in good shape when added to the jar artifact. However, 
> upon generating the project from the archetype, we get the following (note 
> also the whitespace on the blank lines hinting at some indentation attempts, 
> not just the unexpected line breaks)
> {code:java}
> 
>   
>   
>   11
>   
>   
>   Greenwich.RELEASE
>   
> 
>   
> {code}
> This issue does *not* occur in in child module pom.xml files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (ARCHETYPE-584) Resulting root pom.xml from archetype generation has additional newlines with JDK11

2021-07-04 Thread Ruwen Reddig (Jira)



[ 
https://issues.apache.org/jira/browse/ARCHETYPE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374207#comment-17374207
 ] 

Ruwen Reddig commented on ARCHETYPE-584:


[~elharo] googled the problem a bit and [this stackoverflow 
answer|https://stackoverflow.com/a/58481951] provides an explanation that makes 
sense and also fits the expected timeline (change introduced in JDK 9).

 

The change in `ToStream.java` that is mentioned on SO, can be found here: 
https://github.com/openjdk/jdk/commit/1619ba484211c6f1b93fb13e22b507faa5e9d41b

> Resulting root pom.xml from archetype generation has additional newlines with 
> JDK11
> ---
>
> Key: ARCHETYPE-584
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-584
> Project: Maven Archetype
>  Issue Type: Bug
>  Components: Archetypes
>Affects Versions: 3.1.1, 3.1.2
>Reporter: Andre Prata
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This issue does not apply to version 3.1.0, it was introduced in version 
> 3.1.1.
>  
> In our project, we have the default configuration of the root pom.xml that 
> contains lines such as this:
> {code:java}
> 
> 11
> Greenwich.RELEASE
> 
> {code}
> These lines are still in good shape when added to the jar artifact. However, 
> upon generating the project from the archetype, we get the following (note 
> also the whitespace on the blank lines hinting at some indentation attempts, 
> not just the unexpected line breaks)
> {code:java}
> 
>   
>   
>   11
>   
>   
>   Greenwich.RELEASE
>   
> 
>   
> {code}
> This issue does *not* occur in in child module pom.xml files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory

2021-07-04 Thread Alexander Kriegisch (Jira)



[ 
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374206#comment-17374206
 ] 

Alexander Kriegisch commented on SUREFIRE-1881:
---

The issue might be fixed, but there are problems in the new test(s), see 
https://github.com/apache/maven-surefire/pull/355. I think we should reopen.

> Java agent printing to native console makes build block when using 
> SurefireForkNodeFactory
> --
>
> Key: SUREFIRE-1881
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1881
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Alexander Kriegisch
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
> Attachments: Bildschirmfoto von 2021-03-29 21-50-25.png, 
> image-2021-02-08-12-07-34-183.png, image-2021-03-26-09-48-11-398.png, 
> image-2021-03-26-09-52-36-881.png, image-2021-03-26-18-00-37-889.png, 
> image-2021-03-31-11-22-50-682.png, image-2021-03-31-11-38-11-119.png, 
> image-2021-03-31-12-31-55-818.png, image-2021-03-31-12-32-41-589.png, 
> maven-failsafe-debug-log.txt, screenshot-1.png, screenshot-2.png
>
>
> This is a follow-up to SUREFIRE-1788 which was closed prematurely even though 
> there still were open issues which were discussed there initially. Basically 
> the situation is as follows:
>  * I use Java agents writing to stdOut and stdErr in my tests.
>  * I was annoyed that Surefire/Failsafe were writing lots of {{[WARNING] 
> Corrupted STDOUT by directly writing to native stream in forked JVM}} lines 
> into {{*-jvmRun1.dumpstream}} files. [~tibordigana] then told me to use 
> {{ implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory"/>}}
>  in my POM in order to fix the issue.
>  * I tried this in version 3.0.0-M5, but unfortunately, it makes 
> Surefire/Failsafe freeze if a Java agent prints something to stdOut or 
> stdErr. This happens both in M5 and in M6-SNAPSHOT after both SUREFIRE-1788 
> and SUREFIRE-1809 have been merged in already.
>  * My [sample 
> project|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems] 
> reproduces the issue as soon as you uncomment the option in the POM and run 
> {{mvn clean verify}}.
>  * The second issue is: *Not* using this option leads to garbled log output 
> when a Java agent writes to both stdOut and stdErr before/during tests. See 
> comments in class 
> [{{Agent.DummyTransformer}}|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems/blob/master/src/main/java/de/scrum_master/dummy/Agent.java]
>  for examples for garbled log lines and also comments in 
> [pom.xml|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems/blob/master/pom.xml#L36]
>  for further information.
>  * If the garbled output would also appear with this option activated, cannot 
> be tested at present due to the Surefire/Failsafe freeze. I will re-test that 
> after the freeze has been fixed and before this issue can be closed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-surefire] kriegaex edited a comment on pull request #354: [SUREFIRE-1881] Adds additional debug log and fork connection timeout



kriegaex edited a comment on pull request #354:
URL: https://github.com/apache/maven-surefire/pull/354#issuecomment-873530804


   @Tibor17, I think you were a bit too fast to merge this, because
 * the new IT was never executed by Maven due to faulty naming,
 * you only added one test case instead of two,
 * you did not test properly what happens when a timeout occurs (hanging 
JVMs are not terminated).
   
   I addressed the first two points in a new PR #355 and explained the third 
one (yet unsolved).
   
   ---
   
   BTW, so we do not forget it: Did you create the new PR and Jira issue for 
the mixed up logging problem? I just saw you closed this PR and the 
corresponding Jira issue. This bears the danger of forgetting the other problem.


-- 
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] kriegaex commented on pull request #354: [SUREFIRE-1881] Adds additional debug log and fork connection timeout



kriegaex commented on pull request #354:
URL: https://github.com/apache/maven-surefire/pull/354#issuecomment-873530804


   @Tibor17, I think you were a bit too fast to merge this, because
 * the new IT was never executed by Maven due to faulty naming,
 * you only added one test case instead of two,
 * you did not test properly what happens when a timeout occurs (hanging 
JVMs are not terminated).
   
   I addressed the first two points in a new PR and explained the third one 
(yet unsolved).
   
   ---
   
   BTW, so we do not forget it: Did you create the new PR and Jira issue for 
the mixed up logging problem? I just saw you closed this PR and the 
corresponding Jira issue. This bears the danger of forgetting the other problem.


-- 
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] kriegaex opened a new pull request #355: [SUREFIRE-1881] - Fix and extend integration test