[jira] [Created] (MNG-7536) Mojo execution locking in Maven 3.8.5 deadlocks my plugin
David Elliott created MNG-7536: -- Summary: Mojo execution locking in Maven 3.8.5 deadlocks my plugin Key: MNG-7536 URL: https://issues.apache.org/jira/browse/MNG-7536 Project: Maven Issue Type: Bug Affects Versions: 3.8.6, 3.8.5 Reporter: David Elliott Attachments: thread-example.tar.gz I have an existing mojo which stopped working in Maven 3.8.5 but had been working for years. It looks like MNG-7156 is the cause. This mojo looks through its dependencies for other reactor projects, then looks at those projects for any plugin executions with a special phase name. For all found executions, it executes them in a thread pool as part of some other processing it is doing. My plugin is proprietary and I am unable to share it, but I am able to share a much smaller example illustrating the problem. Being example code, it just spawns a thread to run the mojo executions and attempts to join the thread. In the real code all executions for a given project will run sequentially on one thread, but each project's work will be scheduled concurrently on a thread pool. I didn't feel it was necessary to use a thread pool and schedule more than one project's executions for this example. The deadlock will occur simply by running any mojo at all on a secondary thread while the calling thread is running a mojo waiting for that secondary thread to complete. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7536) Mojo execution locking in Maven 3.8.5 deadlocks my plugin
[ https://issues.apache.org/jira/browse/MNG-7536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600026#comment-17600026 ] David Elliott commented on MNG-7536: [~michael-o]: Per your request here is a new ticket with example code demonstrating the regression I believe to be caused by MNG-7156. > Mojo execution locking in Maven 3.8.5 deadlocks my plugin > - > > Key: MNG-7536 > URL: https://issues.apache.org/jira/browse/MNG-7536 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5, 3.8.6 >Reporter: David Elliott >Priority: Major > Attachments: thread-example.tar.gz > > > I have an existing mojo which stopped working in Maven 3.8.5 but had been > working for years. It looks like MNG-7156 is the cause. > This mojo looks through its dependencies for other reactor projects, then > looks at those projects for any plugin executions with a special phase name. > For all found executions, it executes them in a thread pool as part of some > other processing it is doing. > My plugin is proprietary and I am unable to share it, but I am able to share > a much smaller example illustrating the problem. > Being example code, it just spawns a thread to run the mojo executions and > attempts to join the thread. In the real code all executions for a given > project will run sequentially on one thread, but each project's work will be > scheduled concurrently on a thread pool. > I didn't feel it was necessary to use a thread pool and schedule more than > one project's executions for this example. The deadlock will occur simply by > running any mojo at all on a secondary thread while the calling thread is > running a mojo waiting for that secondary thread to complete. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7536) Mojo execution locking in Maven 3.8.5 deadlocks my plugin
[ https://issues.apache.org/jira/browse/MNG-7536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600027#comment-17600027 ] Michael Osipov commented on MNG-7536: - Thanks for the sample project. [~gnodet], we need to check this sample and see whether and how it qualifies a fix for an upcoming version. Maybe even 3.8.7. > Mojo execution locking in Maven 3.8.5 deadlocks my plugin > - > > Key: MNG-7536 > URL: https://issues.apache.org/jira/browse/MNG-7536 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5, 3.8.6 >Reporter: David Elliott >Priority: Major > Attachments: thread-example.tar.gz > > > I have an existing mojo which stopped working in Maven 3.8.5 but had been > working for years. It looks like MNG-7156 is the cause. > This mojo looks through its dependencies for other reactor projects, then > looks at those projects for any plugin executions with a special phase name. > For all found executions, it executes them in a thread pool as part of some > other processing it is doing. > My plugin is proprietary and I am unable to share it, but I am able to share > a much smaller example illustrating the problem. > Being example code, it just spawns a thread to run the mojo executions and > attempts to join the thread. In the real code all executions for a given > project will run sequentially on one thread, but each project's work will be > scheduled concurrently on a thread pool. > I didn't feel it was necessary to use a thread pool and schedule more than > one project's executions for this example. The deadlock will occur simply by > running any mojo at all on a secondary thread while the calling thread is > running a mojo waiting for that secondary thread to complete. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-enforcer] raupachz opened a new pull request, #183: [MENFORCER-430] Allow one of many files in RequireFiles rules to pass
raupachz opened a new pull request, #183: URL: https://github.com/apache/maven-enforcer/pull/183 This PR resolves the issue [MENFORCER-430](https://maven.apache.org/enforcer/enforcer-rules/requireFilesExist.html). Given a list of files it was not possible to enforce only a list where only one filed would be sufficient. For example check if one of the following files exists: * README * README.md * README.adoc A new paramenter `satisfyAny` was added to `AbstractRequiresFiles`. If `satisfyAny` is `true` then it is enough if one of the files passes the check. This PR affects the following built-in rules: * RequireFilesDontExist * RequireFilesExist * RequireFilesSize Tests have been added. I do not know if the [documentation of the builtin-rules](https://maven.apache.org/enforcer/enforcer-rules/requireFilesExist.html) updates itself with the new paramenter `satisfyAny` or if I have to do this myself. Please note this is an `up-for-grabs` issue and given my lack of experience in Maven Development I might have missed something. --- Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MENFORCER) 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. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MENFORCER-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MENFORCER-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. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MENFORCER-430) Allow one of many files in RequireFiles rules to pass
[
https://issues.apache.org/jira/browse/MENFORCER-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600042#comment-17600042
]
Björn Raupach commented on MENFORCER-430:
-
Hi there. I opened a PR. Looking for feedback. Thanks!
> Allow one of many files in RequireFiles rules to pass
> -
>
> Key: MENFORCER-430
> URL: https://issues.apache.org/jira/browse/MENFORCER-430
> Project: Maven Enforcer Plugin
> Issue Type: New Feature
>Reporter: Slawomir Jaranowski
>Priority: Major
> Labels: up-for-grabs
>
> Currently rules {{RequireFiles...}} require that all given files must satisfy
> rule.
> We can add new parameters like {{satisfyAny}} with default value to
> {{false}}, which allow that one of files can make rule to pass.
> Implementation should be done in {{AbstractRequireFiles}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-dependency-tree] dependabot[bot] commented on pull request #24: Bump slf4j-api from 1.7.36 to 2.0.0
dependabot[bot] commented on PR #24: URL: https://github.com/apache/maven-dependency-tree/pull/24#issuecomment-1236335992 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-dependency-tree] slachiewicz closed pull request #24: Bump slf4j-api from 1.7.36 to 2.0.0
slachiewicz closed pull request #24: Bump slf4j-api from 1.7.36 to 2.0.0 URL: https://github.com/apache/maven-dependency-tree/pull/24 -- 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-build-cache-extension] hboutemy merged pull request #22: fix link
hboutemy merged PR #22: URL: https://github.com/apache/maven-build-cache-extension/pull/22 -- 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-build-cache-extension] hboutemy commented on pull request #22: fix link
hboutemy commented on PR #22: URL: https://github.com/apache/maven-build-cache-extension/pull/22#issuecomment-1236357398 thanks -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-build-cache-extension] hboutemy commented on pull request #7: Broken Link: Usage of .md causes apache.org documentation 404
hboutemy commented on PR #7: URL: https://github.com/apache/maven-build-cache-extension/pull/7#issuecomment-1236357637 link fixed in #22 -- 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-build-cache-extension] hboutemy closed pull request #7: Broken Link: Usage of .md causes apache.org documentation 404
hboutemy closed pull request #7: Broken Link: Usage of .md causes apache.org documentation 404 URL: https://github.com/apache/maven-build-cache-extension/pull/7 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-2073) Test class filtering should be done in the particular fork JVM where the real test would run.
[
https://issues.apache.org/jira/browse/SUREFIRE-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600071#comment-17600071
]
Niels Basjes commented on SUREFIRE-2073:
I ran into something that seems very similar to this issue.
I put the smallest reproduction I could create here:
[https://github.com/nielsbasjes/MavenSurefireForkCount]
My key question: Did I run into this issue, or is this something different?
> Test class filtering should be done in the particular fork JVM where the real
> test would run.
> -
>
> Key: SUREFIRE-2073
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2073
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M6
>Reporter: Piotr Karwasz
>Priority: Major
> Fix For: 3.0
>
>
> On projects using toolchains submodules can be compiled with a different Java
> version than the main project. This can result in an
> {{UnsupportedClassVersionError}} if the class scan is performed by the main
> Maven JVM:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (test) on
> project log4j-api-java9: Execution test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed:
> java.lang.UnsupportedClassVersionError:
> org/apache/logging/log4j/util/java9/ProcessIdUtilTest has been compiled by a
> more recent version of the Java Runtime (class file version 53.0), this
> version of the Java Runtime only recognizes class file versions up to 52.0 ->
> [Help 1]{noformat}
> Therefore Surefire should probably fork a new instance to scan for test
> classes whenever {{forkCount}} is not zero.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-mvnd] euvitudo opened a new issue, #681: ClassNotFoundException when starting jetty with jetty-maven-plugin
euvitudo opened a new issue, #681: URL: https://github.com/apache/maven-mvnd/issues/681 I've been seeing this issue where running `mvnd` on a project with jetty-maven-plugin configured for for functional tests, fails to property start jetty with a `ClassNotFoundException` on `javax.servlet.ServletContainerInitializer` while Jetty remains running. Running `mvn clean install` works as expected. Please see the example project: https://github.com/euvitudo/mvnd-jetty-plugin-issue/tree/main -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-shade-plugin] dependabot[bot] merged pull request #125: Bump xmlunit-legacy from 2.7.0 to 2.9.0
dependabot[bot] merged PR #125: URL: https://github.com/apache/maven-shade-plugin/pull/125 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] Eskibear commented on pull request #178: [MRESOLVER-7] download poms in parallel
Eskibear commented on PR #178: URL: https://github.com/apache/maven-resolver/pull/178#issuecomment-1236566854 > Proper evaluation I'd mandatory I understand and appreciate all the work you guys have done. If I remember clearly, some integration tests and details were discussed in a private ASF slack channel which I had no access... Just want to know if there's any ETA (already one month since last update)? Anyway, please let me know if there's anything I can help (if that would help to proceed 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
[jira] [Commented] (MRESOLVER-7) Download dependency POMs in parallel
[ https://issues.apache.org/jira/browse/MRESOLVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600212#comment-17600212 ] ASF GitHub Bot commented on MRESOLVER-7: Eskibear commented on PR #178: URL: https://github.com/apache/maven-resolver/pull/178#issuecomment-1236566854 > Proper evaluation I'd mandatory I understand and appreciate all the work you guys have done. If I remember clearly, some integration tests and details were discussed in a private ASF slack channel which I had no access... Just want to know if there's any ETA (already one month since last update)? Anyway, please let me know if there's anything I can help (if that would help to proceed this). > Download dependency POMs in parallel > > > Key: MRESOLVER-7 > URL: https://issues.apache.org/jira/browse/MRESOLVER-7 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: Aether 1.0.2 >Reporter: Harald Wellmann >Priority: Major > Attachments: resolve_deps.png, resolver.log > > Time Spent: 40m > Remaining Estimate: 0h > > h3. Background > When building a project with dependencies not yet available in the local > repository, I noticed that Maven 3.3.9/Aether 1.0.2 first downloads the > dependency POMs _sequentially_ and then proceeds downloading the dependency > JARs with up to 5 threads _in parallel_. > Due to this, when first building a project with a large number of > dependencies, downloading a large number of small POMs may take a lot longer > than downloading the much larger JARs, or even longer than building the > project itself, especially when a repository manager is used which increases > the download latency. > h3. Enhancement > Download POMs of (transitive) dependencies in parallel to significantly speed > up initial builds of large projects. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-build-cache-extension] hboutemy commented on pull request #24: [MBUILDCACHE-22] added possibility to skip cache lookup per project or globally
hboutemy commented on PR #24: URL: https://github.com/apache/maven-build-cache-extension/pull/24#issuecomment-1236595784 is it possible to add a note in documentation about this feature and how to use it, please? https://github.com/apache/maven-build-cache-extension/tree/master/src/site/markdown -- 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] (MBUILDCACHE-22) Add possibility to skip cache lookup
[ https://issues.apache.org/jira/browse/MBUILDCACHE-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated MBUILDCACHE-22: -- Labels: pull-request-available (was: ) > Add possibility to skip cache lookup > > > Key: MBUILDCACHE-22 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-22 > Project: Maven Build Cache Extension > Issue Type: New Feature > Components: remote build cache >Affects Versions: 1.0.0-alpha >Reporter: Alexander Eltsov >Priority: Major > Labels: pull-request-available > > Add ability to skip cache lookup for a particular module or whole project > (required to get some modules always built e.g. via a profile - e.g. I have > some additional artifacts published by CI). > Alternatively it allows an easy "force" rebuild of a whole project > The difference with not using cache is that results are put into cache, just > current matching versions are not taken from caches -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-22) Add possibility to skip cache lookup
[ https://issues.apache.org/jira/browse/MBUILDCACHE-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600225#comment-17600225 ] ASF GitHub Bot commented on MBUILDCACHE-22: --- hboutemy commented on PR #24: URL: https://github.com/apache/maven-build-cache-extension/pull/24#issuecomment-1236595784 is it possible to add a note in documentation about this feature and how to use it, please? https://github.com/apache/maven-build-cache-extension/tree/master/src/site/markdown > Add possibility to skip cache lookup > > > Key: MBUILDCACHE-22 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-22 > Project: Maven Build Cache Extension > Issue Type: New Feature > Components: remote build cache >Affects Versions: 1.0.0-alpha >Reporter: Alexander Eltsov >Priority: Major > > Add ability to skip cache lookup for a particular module or whole project > (required to get some modules always built e.g. via a profile - e.g. I have > some additional artifacts published by CI). > Alternatively it allows an easy "force" rebuild of a whole project > The difference with not using cache is that results are put into cache, just > current matching versions are not taken from caches -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-shade-plugin] slawekjaranowski commented on pull request #150: [MSHADE-425] Relocate services name before add to serviceEntries
slawekjaranowski commented on PR #150: URL: https://github.com/apache/maven-shade-plugin/pull/150#issuecomment-1236607084 @tisonkun Thanks for your PR. We need a unit test to be sure that next change don't break 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-shade-plugin] tisonkun commented on pull request #150: [MSHADE-425] Relocate services name before add to serviceEntries
tisonkun commented on PR #150: URL: https://github.com/apache/maven-shade-plugin/pull/150#issuecomment-1236608636 @slawekjaranowski Yes. I ever thought of this. Let me try to dig out how to add one. Or could you show me some related tests. -- 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] slawekjaranowski commented on pull request #150: [MSHADE-425] Relocate services name before add to serviceEntries
slawekjaranowski commented on PR #150: URL: https://github.com/apache/maven-shade-plugin/pull/150#issuecomment-1236609841 I don't investigate deeper - only mention about missing test -- 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
