How see all non threadsafe plugins in maven?
Asked Answered
C

2

8

I have read about maven parallel build configuration in this. So how I can display all non thread safe plugins? Is there something like "plugin-not-safe-list" command in maven?

REM something like that to display all p[lugins without @threadSafe  annotation
mvn help:plugin-not-safe-list
Containerize answered 25/6, 2014 at 11:34 Comment(0)
D
4

Now when you build Maven warns about plugins not marked as threadsafe:

[WARNING] *****************************************************************
[WARNING] * Your build is requesting parallel execution, but project      *
[WARNING] * contains the following plugin(s) that have goals not marked   *
[WARNING] * as @threadSafe to support parallel building.                  *
[WARNING] * While this /may/ work fine, please look for plugin updates    *
[WARNING] * and/or request plugins be made thread-safe.                   *
[WARNING] * If reporting an issue, report it against the plugin in        *
[WARNING] * question, not against maven-core                              *
[WARNING] *****************************************************************
[WARNING] The following plugins are not marked @threadSafe in Root Maven Parent:
[WARNING] com.googlecode.maven-download-plugin:download-maven-plugin:1.3.0
[WARNING] Enable debug to see more precisely which goals are not marked @threadSafe.
[WARNING] *****************************************************************
Dumyat answered 15/4, 2020 at 14:58 Comment(0)
A
1

You can write custom rule for maven-enforcer-plugin and use it for running on your maven project.

You might also want to use the mojo-executor to parse the plugin.xml file for checking its "thread safe" property.

A little elaboration on when and why you should use the above. When you are working in CI/CD environment, and you want to employ the parallel compilation via maven, you should constantly monitor that your developers are not adding non-thread safe plugins, in order to ensure the consistency and correctness of the CI/CD. In order to achieve that, you can use the above mentioned maven-envorcer-plugin with custom rule. Your custom rule can use the Maven Plugin API (maven project, etc.) in order to search all the plugins in the projects, and then use the mojo-executor lib in order to read the threadSafe property of each plugin (since the maven API does not provide that). mojo-executor lib has tools to parse the plugin.xml file of a maven plugin where the threadSafe property resides. Once found, you can fail the maven build.

If you want to see only the list of the non-thread safe plugins, you can use the same technique, and just list the plugins which threadSafe property is false. You can then configure the maven-enforcer-plugin to use the custom rule (for example, a profile of the project), and run it via command line in a single maven command.

BTW, what happens when you find a non-thread safe plugin in your development project, and there are no thread safe alternatives, is another question, which is also solvable.

Ambivalence answered 19/10, 2014 at 14:49 Comment(5)
"BTW, what happens when you find a non-thread safe plugin in your development project, and there are no thread safe alternatives, is another question, which is also solvable." could you help to give a detailed explanation how to solve this?Greenebaum
The solution is pretty straight forward, not sure why there is no open source for that yet. I wrote such for my previous employer. You should write a new wrapper plugin, which has a semaphore for not allowing more than one execution in parallel of the same plugin identified by {groupId}+{artifactId}. Since maven executes all the plugins in the same process but different threads in parallel - simple global semaphore should do the trick (singleton). Then for each non-thread safe plugin, you define it via the wrapper pluginAmbivalence
One can say that, it is not real parallelism, if the same plugin will run serially and not in parallel. My tests shown, that on a big enterprise project it is still better than the alternative of running all the build serially. The improvement was 40% less build time with 3 threads. There is a limit on how many threads will give benefit the bulld time, depending on the complexity of the local inter-dependency of the modules in the projectAmbivalence
@Ambivalence are you able to give any more information your synchronisation semaphore solution?Ratcliff
@Ratcliff It was so long ago, I don't remember the details, and I didn't work with maven for the last 5 years. But basically, since maven runs in the same process when parallelized, the wrapper plugin can have a global singleton semaphore, which the different instances of the plugin can acquire before executing the wrapped plugin. I think I will write it as a pet project and shareAmbivalence

© 2022 - 2024 — McMap. All rights reserved.