[
https://issues.apache.org/jira/browse/MNG-7536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653732#comment-17653732
]
David Elliott commented on MNG-7536:
------------------------------------
Unfortunately I cannot because my example doesn't accurately reflect my real
mojo's operation.
For reasons I now don't understand, probably due to my haste in devising an
example, I wrote the example to gather the mojo executions from _other_
projects. But that's not what the real code does. The real code gathers the
mojo executions from the _current_ project, the one running my mojo. So it's
simply not an option for me to execute the mojos in the other projects as
that's not how my code works at all.
Now that I realize this, I'll be the first to admit that it sounds like a
horrible plan to expect that I can run multiple mojo executions in parallel
against the _same_ project. And by extension it seems rather broken to expect
to run anything on a thread other than the one running my mojo.
So I'd say the better approach is for me to fix my plugin so that I run all the
executions sequentially from the thread running the plugin, avoiding a thread
pool at all. Then the whole problem should go away because it should be valid
to execute other mojos recursively from a mojo.
If that doesn't work, I can file a new bug. This one should probably be closed
as Behaves Correctly / Won't Fix.
After reporting this I dug deeper and realized that we no longer need this
mechanism in my mojo and removed all usage of it. Therefore, I no longer have
a real-world test case. Either I'll fix it to run the executions on thread in
case we decide to use it, or I may wind up removing the feature entirely as we
no longer use it and it's unlikely we'll ever need it again.
> 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
> Assignee: Guillaume Nodet
> Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
> 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)
