[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-874045506 Of course you know better than me, which is why I sent my RFC about the open issue (zombie Java processes) in the first place. Now you finally have acknowledged that there actually **is** a problem. Before, you * falsely claimed multiple times that this PR did not contain your previous bugfix, * called the back-ported reproducer test case in the other branch "irrelevant", * did not explicitly acknowledge that the zombie processes are a problem you are going to fix (just acknowledged it now in your most recent 2 comments - thanks for that), * for no good reason copied my commits instead of merging this PR. Those things I was complaining and explaining about. Had you just acknowledged the problem before and somehow signalled that you are intending to fix them, either here or in a new issue/PR, it would have been fine. > `15` Well, that is nowhere to be found in your commits. Besides, I tried that before, both in the IT module settings and in the IT POMs themselves. I also tried the timeout in the IT tests themselves, all to no avail. If you see ways to improve this, I will be glad. BTW, would you please be so kind as to revert your commit (or force-push the previous HEAD) and merge this PR instead? You created your commit under the false notion of my PR not being forked off of master. I really would like to see my own commits here as a small recognition of my contribution. I spent lots of time, trying to explain this PR to you. Of course, I can adjust my PR to be like yours, i.e. a single project with both Surefire and Failsafe settings all in one. If you had told me to do it like that in a normal code review, I would have done so. -- 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-874450203 > Closing as not willing to read tons of text. Great reason, thank you so much. Other OSS maintainers complain about under-specified issues. Your complaint is a luxury complaint. If you have so little time, read more thoroughly, answer more precisely and be happy about saving tons of time due to fewer misunderstandings. > I do not have time to read kilobytes of text for simple issues. Tibor, I am sorry to remind you that all this text would have been unnecessary if you would have read the shorter text in the original issue description correctly. Everything that followed was based on you misunderstanding it due to sloppy reading and first claiming the issue to be irrelevant, before promising to fix it. "You reap what you sow", they say. You are part of the problem, I was not talking to myself here but trying to explain things to you. > Improvements will be fixed as I promised. Thank you, looking forward to it. I promise that despite your dysfunctional and condescending behaviour here, I am still willing to help you re-test this, if you need support. Just notify me in new issues or PRs. -- 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-874450203 > Closing as not willing to read tons of text. Great reason, thank you so much. > I do not have time to read kilobytes of text for simple issues. Tibor, I am sorry to remind you that all this text would have been unnecessary if you would have read the shorter text in the original issue description correctly. Everything that followed was based on you misunderstanding it due to sloppy reading and first claiming the issue to be irrelevant, before promising to fix it. "You reap what you sow", they say. You are part of the problem, I was not talking to myself here but trying to explain things to you. > Improvements will be fixed as I promised. Thank you, looking forward to it. I promise that despite your dysfunctional and condescending behaviour here, I am still willing to help you re-test this, if you need support. Just notify me in new issues or PRs. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-apache-parent] dependabot[bot] opened a new pull request #49: Bump checksum-maven-plugin from 1.10 to 1.11
dependabot[bot] opened a new pull request #49: URL: https://github.com/apache/maven-apache-parent/pull/49 Bumps [checksum-maven-plugin](https://github.com/nicoulaj/checksum-maven-plugin) from 1.10 to 1.11. Commits https://github.com/nicoulaj/checksum-maven-plugin/commit/147b14f52aa21b6705f2917660b935c4e659c601;>147b14f [maven-release-plugin] prepare release 1.11 https://github.com/nicoulaj/checksum-maven-plugin/commit/c472f1a48495f86c7af11ee2b55cf19b7232332b;>c472f1a javadoc fixes https://github.com/nicoulaj/checksum-maven-plugin/commit/d9b4f578117c55b9f47b9ec007f4a6661ede1bb1;>d9b4f57 https://github-redirect.dependabot.com/nicoulaj/checksum-maven-plugin/issues/118;>#118/https://github-redirect.dependabot.com/nicoulaj/checksum-maven-plugin/issues/119;>#119: set required Maven version to 3.1.1 https://github.com/nicoulaj/checksum-maven-plugin/commit/50e1b0c755e33e493b5f76e02403810d480a69bb;>50e1b0c https://github-redirect.dependabot.com/nicoulaj/checksum-maven-plugin/issues/118;>#118/https://github-redirect.dependabot.com/nicoulaj/checksum-maven-plugin/issues/119;>#119: maven-resources-plugin:3.2.0 requires Maven version 3.1.0 = drop ... https://github.com/nicoulaj/checksum-maven-plugin/commit/1d55d1157cb2805060ec11da7470d179bb4a354d;>1d55d11 https://github-redirect.dependabot.com/nicoulaj/checksum-maven-plugin/issues/118;>#118/https://github-redirect.dependabot.com/nicoulaj/checksum-maven-plugin/issues/119;>#119: fix integration tests on Maven=2.1 https://github.com/nicoulaj/checksum-maven-plugin/commit/8a5f5beb74d5eba20305ed336c675b3574c69c1e;>8a5f5be Merge branch 'pr-119' https://github.com/nicoulaj/checksum-maven-plugin/commit/3ec3e781734ceb21d3a83e950017b07d36c70cc3;>3ec3e78 Merge pull request https://github-redirect.dependabot.com/nicoulaj/checksum-maven-plugin/issues/121;>#121 from nicoulaj/ci-setup-java https://github.com/nicoulaj/checksum-maven-plugin/commit/7d3393b92be46bb93f69426720b745fe61101af4;>7d3393b CI: move to setup-java action https://github.com/nicoulaj/checksum-maven-plugin/commit/7a490c9acd6b2a4d74590b2e58ecce117a9df2e6;>7a490c9 update parent POM, cleanup and inherit versions from parent POM https://github.com/nicoulaj/checksum-maven-plugin/commit/4d3cf643d5f00c33884705fa0d4205f43341f96b;>4d3cf64 CI: build on all branches Additional commits viewable in https://github.com/nicoulaj/checksum-maven-plugin/compare/1.10...1.11;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MPOM-244) Deploy SHA-512 for source-release to Remote Repository
[ https://issues.apache.org/jira/browse/MPOM-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374979#comment-17374979 ] Julien Nicoulaud commented on MPOM-244: --- Hi guys, I just released version 3.11 of checksum-maven-plugin that restores compatibility with Maven 3.1.1. > Deploy SHA-512 for source-release to Remote Repository > -- > > Key: MPOM-244 > URL: https://issues.apache.org/jira/browse/MPOM-244 > Project: Maven POMs > Issue Type: Improvement > Components: asf >Affects Versions: ASF-23 >Reporter: Konrad Windszus >Assignee: Herve Boutemy >Priority: Major > Fix For: ASF-24 > > > As now the ASF staging repository supports SHA2 hashes > (https://issues.apache.org/jira/browse/INFRA-14923) they should be generated > for > - the ASF source release artifact (as recommended in > https://infra.apache.org/release-distribution.html#sigs-and-sums) > - deployed to the Staging repository (i.e. attached to build as well) -- 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-874045506 Of course you know better than me, which is why I sent my RFC about the open issue (zombie Java processes) in the first place. Now you finally have acknowledged that there actually **is** a problem. Before you * falsely claimed multiple times that this PR did not contain your previous bugfix, * called the back-ported reproducer test case in the other branch "irrelevant", * did not explicitly acknowledge that the zombie processes are a problem you are going to fix (just acknowledged it now in your most recent 2 comments - thanks for that), * for no good reason copied my commits instead of merging this PR. Those things I was complaining and explaining about. Had you just acknowledged the problem before and somehow signalled that you are intending to fix them, either here or in a new issue/PR, it would have been fine. > `15` Well, that is nowhere to be found in your commits. Besides, I tried that before, both in the IT module settings and in the IT POMs themselves. I also tried the timeout in the IT tests themselves, all to no avail. If you see ways to improve this, I will be glad. BTW, would you please be so kind as to revert your commit (or force-push the previous HEAD) and merge this PR instead? You created your commit under the false notion of my PR not being forked off of master. I really would like to see my own commits here as a small recognition of my contribution. I spent lots of time, trying to explain this PR to you. Of course, I can adjust my PR to be like yours, i.e. a single project with both Surefire and Failsafe settings all in one. If you had told me to do it like that in a normal code review, I would have done so. -- 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 closed pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Tibor17 closed pull request #355: URL: https://github.com/apache/maven-surefire/pull/355 -- 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-874191056 @kriegaex Closing as not willing to read tons of text. I do not have time to read kilobytes of text for simple issues. Improvements will be fixed as I promised. -- 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 #486: Use the MX xpp parser instead of a STAX transformation
michael-o commented on pull request #486: URL: https://github.com/apache/maven/pull/486#issuecomment-874185595 I think this needs a JIRA issue. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] gnodet opened a new pull request #486: Use the MX xpp parser instead of a STAX transformation
gnodet opened a new pull request #486: URL: https://github.com/apache/maven/pull/486 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] [Closed] (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 closed MNG-7169.
---
Fix Version/s: (was: waiting-for-feedback)
Resolution: Not A Problem
> 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] (SUREFIRE-1926) Console logs should be synchronized
[ https://issues.apache.org/jira/browse/SUREFIRE-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374784#comment-17374784 ] Michael Osipov commented on SUREFIRE-1926: -- Your explanation makes sense. > 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-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-874045506 Of course you know better than me, which is why I sent my RFC about the open issue (zombie Java processes) in the first place. Now you finally have acknowledged that there actually **is** a problem. Before you * falsely claimed multiple times that this PR did not contain your previous bugfix, * called the back-ported reproducer test case in the other branch "irrelevant", * did not explicitly acknowledge that the zombie processes are a problem you are going to fix (just just acknowledged it now in your most recent 2 comments - thanks for that), * for no good reason copied my commits instead of merging this PR. Those things I was complaining and explaining about. Had you just acknowledged the problem before and somehow signalled that you are intending to fix them, either here or in a new issue/PR, it would have been fine. > `15` Well, that is nowhere to be found in your commits. Besides, I tried that before, both in the IT module settings and in the IT POMs themselves. I also tried the timeout in the IT tests themselves, all to no avail. If you see ways to improve this, I will be glad. BTW, would you please be so kind as to revert your commit (or force-push the previous HEAD) and merge this PR instead? You created your commit under the false notion of my PR not being forked off of master. I really would like to see my own commits here as a small recognition of my contribution. I spent lots of time, trying to explain this PR to you. Of course, I can adjust my PR to be like yours, i.e. a single project with both Surefire and Failsafe settings all in one. If you had told me to do it like that in a normal code review, I would have done so. -- 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-874045506 Of course you know better than me, which is why I sent my RFC about the open issue (zombie Java processes) in the first place. Now you finally have acknowledged that there actually **is** a problem. Before you * falsely claimed multiple times that this PR did not contain your previous bugfix, * called the back-ported reproducer test case in the other branch "irrelevant", * did not explicitly acknowledge that the zombie processes are a problem you are going to fix (just just acknowledged it now in your most recent 2 comments - thanks for that), * for no good reason copied my commits instead of merging this PR. Those things I was complaining and explaining about. Had you just acknowledged the problem before and somehow signalled that you are intending to fix them, either here or in a new issue/PR, it would have been fine. > 15 Well, that is nowhere to be found in your commits. Besides, I tried that before, both in the IT module settings and in the IT POMs themselves. I also tried the timeout in the IT tests themselves, all to no avail. If you see ways to improve this, I will be glad. BTW, would you please be so kind as to revert your commit (or force-push the previous HEAD) and merge this PR instead? You created your commit under the false notion of my PR not being forked off of master. I really would like to see my own commits here as a small recognition of my contribution. I spent lots of time, trying to explain this PR to you. -- 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 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-874015200 zombie process may happen if and only if two things happen: 1. enabled TCP impl is broken (default PING mechanism does not inform surefire subprocess that Maven has stopped) 2. Maven build was interrupter/stopped in surefire/failsafe plugin. It is not so critical at the moment but it may happen. I will open Jira ticket and i will think about the old config param. -- 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-874015200 zombie process may happen if and only if two things happen: 1. enabled TCP impl is broken (default PING mechanism does not inform surefire subprocess that Maven has stopped) 2. Maven build was interrupter/stopped in surefire/failsafe plugin. It is not so critical at the moment but it may happen. I will open Jira ticket and i will think about the old config param. -- 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-874011834 @kriegaex I have the source code in my mind and I know what should be done with the config parameter `15`. You can see this in my commit. Do you know how it works? You have to trust me that I know better than you and I take the responsibility for zombie processes. I am aware that they may happen in the TCP is broken again and that the user has to use `forkedProcessTimeoutInSeconds` but it cannot be solved like this in this PR. We have some way to inform the users about the features in surefire and their possible issues and we can propose treatments. I can see the risk in the ITs and we know what should be done, but the problem with this PR looks like a bug after HEAD commit in master - that's the problem, and many other contributors use to write straightforward and brief definition of issue. We need to have time to think about a solution to keep backward compatibility with `forkedProcessTimeoutInSeconds` and provide a solution b ut the brain needs to have the time to think about it and this is normal. And normal is to post an issue in Jira to not to forget it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (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=17374760#comment-17374760
]
Timm Fitschen commented on MNG-7169:
After further investigation, I found that debian patches the maven package to
use guice from the debian package "guice-4.2.1" instead of using the
"guice-no_aop.jar" in the maven dist-build.
So, installing maven-core from the original binary package solved this issue
for me.
Please close. Thank you.
> 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 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-873987237 What are you talking about? I didn't **want** to write so much, if it wasn't so super hard to convince you of anything. But obviously you don't understand that this is a real problem and didn't care to investigate by yourself or acknowledge the zombie processes as a problem. Instead, you criticised that I used an admin tool with a GUI instead of a console tool. We should care about this problem because none other than Maven creates the zombie processes, they don't appear magically. When running the IT directly from its POM and pressing Ctrl-C, all child processes are terminated correctly. Only when running as part of the Surefire ITs, the zombie processes occur. How on earth can you **not** care and simply ignore an obvious, reproducible problem which is a huge system resource leak? -- 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-873987237 What are you talking about? I didn't **want** to write so much, if it wasn't so super hard to convince you of anything. But obviously you don't understand that this is a real problem and didn't care to investigate by yourself or acknowledge the zombie processes as a problem. Instead, you criticised that I used an admin tool with a GUI instead of a console tool. We should care about this problem because none other than Maven creates them, they don't appear magically. When running the IT directly from its POM and pressing Ctrl-C, all child processes are terminated correctly. Only when running as part of the Surefire ITs, the zombie processes occur. How on earth can you **not** care and simply ignore an obvious, reproducible problem which is a huge system resource leak? -- 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-873987237 What are you talking about? I didn't **want** to write so much, if it wasn't so super hard to convince you of anything. But obviously you don't understand that this is a real problem and didn't care to investigate by yourself or acknowledge the zombie processes as a real problem. Instead, you criticised that I used an admin tool with a GUI instead of a console tool. We should care about this problem because none other than Maven creates them, they don't appear magically. When running the IT directly from its POM and pressing Ctrl-C, all child processes are terminated correctly. Only when running as part of the Surefire ITs, the zombie processes occur. How on earth can you **not** care and simply ignore an obvious, reproducible problem which is a huge system resource leak? -- 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-873987237 What are you talking about? I didn't **want** to write so much, if it wasn't so shower hard to convince you of anything. But obviously you don't understand that this is a real problem and didn't care to investigate by yourself or acknowledge the zombie processes as a real problem. Instead, you criticised that I used an admin tool with a GUI instead of a console tool. We should care about this problem because none other than Maven creates them, they don't appear magically. When running the IT directly from its POM and pressing Ctrl-C, all child processes are terminated correctly. Only when running as part of the Surefire ITs, the zombie processes occur. How on earth can you **not** care and simply ignore an obvious, reproducible problem which is a huge system resource leak? -- 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-873987237 What are you talking about? I don't wanted to write so much, but obviously didn't understand that this is a real problem and didn't care to investigate by yourself or acknowledge the zombie processes as a real problem. Instead, you criticised that I used an admin tool with a GUI instead of a console tool. We should care about this problem because none other than Maven creates them, they don't appear magically. When running the IT directly from its POM and pressing Ctrl-C, all child processes are terminated correctly. Only when running as part of the Surefire ITs, the zombie processes occur. How on earth can you **not** care and simply ignore an obvious, reproducible problem which is a huge system resource leak? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-1926) Console logs should be synchronized
[ https://issues.apache.org/jira/browse/SUREFIRE-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374736#comment-17374736 ] Tibor Digana commented on SUREFIRE-1926: [~michael-o] I do not require a fix in Maven. This can be easily done in surefire implementation. > 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)
[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=17374735#comment-17374735 ] Tibor Digana commented on SUREFIRE-1926: [~michael-o] Actually both slf4j and sysout need to be in one lock. The reason is that the test summary goes through slf4j (normal maven logger - apache api) but the console logs (a user calls System.out.println() in his tests) appear in sysout and syserr. > 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-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-873976776 @kriegaex It is not understandable that you are able to spend our time on these thing. You can write some document in DZone on "How to find zombie process in java" but we are not interested in this elaborate document! -- 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] rfscholte commented on pull request #26: [MSHADE-326] Hide shaded dependencies from the rest of the reactor build
rfscholte commented on pull request #26: URL: https://github.com/apache/maven-shade-plugin/pull/26#issuecomment-873934570 IIUC this is caused by Maven 3 using the pom.xml of the reactor for both build and consume. With Maven 4 we've started to separate this, but currently not inside the reactor. As long as Maven can ensure that the consumer-pom won't introduce new reactor dependencies, it should be possible inside Maven. I don't think this should be solved at plugin level as there are more that suffer from the same issue. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-shade-plugin] JanMosigItemis commented on pull request #83: [MSHADE-366] - "Access denied" during 'minimizeJar'
JanMosigItemis commented on pull request #83: URL: https://github.com/apache/maven-shade-plugin/pull/83#issuecomment-873919166 Thx again for the input. I guess, this means, PR #83 may be closed without merge? -- 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-7161) Error thrown during uninstalling of JAnsi
[
https://issues.apache.org/jira/browse/MNG-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374662#comment-17374662
]
Guy Brand commented on MNG-7161:
[~michael-o] Yes I'll try to have something ready by the end of this week.
> Error thrown during uninstalling of JAnsi
> -
>
> Key: MNG-7161
> URL: https://issues.apache.org/jira/browse/MNG-7161
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.2, 4.0.0, 4.0.0-alpha-1
>Reporter: Guy Brand
>Priority: Critical
> Fix For: 4.0.x-candidate, 3.8.x-candidate
>
>
> Our integration tests stopped working after we started to test with a Maven
> {{4.0.0-alpha-1}} nightly which included this commit:
> [https://github.com/apache/maven/commit/195fb626a9a4e5a0774f779b6d8da1cb9ef38468#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R310-R317]
> In this commit the {{maven-shared-utils}} and the {{jansi}} dependencies are
> being upgraded. When we then run our integration tests we get the following
> null pointer exception:
> {code:java}
> java.lang.NullPointerException
> at org.fusesource.jansi.AnsiPrintStream.uninstall(AnsiPrintStream.java:79)
> at org.fusesource.jansi.AnsiConsole.systemUninstall(AnsiConsole.java:524)
> at
> org.apache.maven.shared.utils.logging.MessageUtils.doSystemUninstall(MessageUtils.java:101)
> at
> org.apache.maven.shared.utils.logging.MessageUtils.systemUninstall(MessageUtils.java:80)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> {code}
>
> We debugged this and [these
> changes|https://github.com/fusesource/jansi/commit/63bd892b2bdfc253ec119a57bdd42df5e80fd859#diff-d59db8655d9ae2d11948e2b411c34fc9e8513f29065d82c978d7128dafbe3bafR414-R420]
> in JAnsi introduced in the above upgraded version, is the source of the
> exception. The NPE is caused because the {{out}} reference is {{null}} at the
> time it wants to uninstall the {{AnsiOutputStream}}. This reference is nulled
> because we use the Plexus interactivity library which [disposes the
> {{DefaultOutputHandler}}|https://github.com/codehaus-plexus/plexus-interactivity/blob/master/plexus-interactivity-api/src/main/java/org/codehaus/plexus/components/interactivity/DefaultOutputHandler.java#L51-L54]
> on the tear down of Plexus, in which the {{System.out}} reference will be
> closed which is in fact the {{out}} reference of the {{AnsiConsole}} JAnsi
> will be [initialized
> before|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L200]
> the Plexus container). This happens
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L202],
> so before JAnsi will be uninstalled in
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L203].
> There are two options to solve this:
> 1. Report this to JAnsi such that they catch this valid use case and do not
> throw as this worked without any exceptions in older versions.
> 2. Fix the {{MessageUtils#doSystemUninstall()}} and catch all exceptions and
> swallow them, as if it can't uninstall it, then Maven itself is not capable
> of fixing this state either. This is already done in a similar way
> [here|https://github.com/apache/maven-shared-utils/blob/17091d82508deb9b7067f3434ba16f660ffc5023/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java#L85-L92]
> for removing the shutdown hook.
> Our proposal is to do #2 which would make Maven itself resilient to such use
> cases as there are other extensions/plugin out there which also retrieve a
> reference for the system output streams and therefore they would fail with
> Maven 4.0.0. This would also make this part future proof, as when there are
> other errors thrown during the uninstall, Maven itself does not break.
> We can as well report this to JAnsi too such that this gets fixed there as
> well.
>
> What
[GitHub] [maven] michael-o closed pull request #485: [MNG-6241] Load -Dstyle.color from system properties also
michael-o closed pull request #485: URL: https://github.com/apache/maven/pull/485 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] 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-873874509 Closing since this isn't the right approach. -- 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-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=17374602#comment-17374602
]
Michael Osipov commented on MNG-6241:
-
It seems so. I will close the PR meanwhile.
> 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] [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=17374581#comment-17374581
]
Martin Kanters commented on MNG-6241:
-
As [~rfscholte] mentioned on GitHub that he does not prefer the system property
solution, perhaps we could take a look at using or introducing another
environment variable for setting Maven flags. There is a way to specify this in
the
[.mvn/maven.config|https://maven.apache.org/configure.html#mvn-maven-config-file]
file, so what if we combine that with a new env variable (e.g.
MVN_FLAGS_CONFIG or something..). I understand from the same docs that MVN_OPTS
is not a right fit for this, as it should only contain JVM options. I don't
really like introducing a new env var for this, but it seems we have a gap
here, if I understand it correctly.
> 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)
