[
https://issues.apache.org/jira/browse/MNG-7536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17601872#comment-17601872
]
Guillaume Nodet commented on MNG-7536:
--------------------------------------
The problem is located in your plugin.
With maven 3.8.6, the execution displays a better warning:
{code}
WARNING] *****************************************************************
[WARNING] * The org.example:thread-example:1.0-SNAPSHOT:post-exec mojo *
[WARNING] * is already being executed on the project *
[WARNING] * org.example.it:simple-it. This mojo execution will be *
[WARNING] * blocked until the mojo is done. *
[WARNING] *****************************************************************
{code}
This indicates where the error comes from. The forked executions are
"executed" on the originating project instead of the dependent projects, so the
lock just waits forever. Specifying the correct project solves the problem.
In your plugin, simply replace
{code}
mojoExecution.setForkedExecutions(getProjectKey(project),
mojoExecutions);
{code}
with
{code}
mojoExecution.setForkedExecutions(getProjectKey(p), mojoExecutions);
{code}.
> 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)
