Stephen Connolly wrote:

... but each release of m3
would have it's own compatibility info and we would have another state:
unknown

e.g.

<thread-safety>
   <plugin groupId="..." artifactId="...">
     <wieve-mode action="ban" versions="...">message</wieve-mode>
     <wieve-mode action="warn" versions="...">message</wieve-mode>
     <wieve-mode action="checked" versions="..."/>
     <parallel-mode action="ban" versions="...">message</paralle-mode>
     <parallel-mode action="warn" versions="...">message</paralle-mode>
     <parallel-mode action="checked" versions="...">message</paralle-mode>
   </plugin>
</thread-safety>

Any plugins not in the list would be "unknown" and the user gets a big fat
warning

Did you also consider the maintainability aspect of such a list? No user wants to see "big fat warnings" that are irrelevant for their builds so I envision users will either bug the plugin author or us directly to add plugin X to this list and ask us to roll a new release of this list such that they get rid of that warning.

Plugins should be self-describing, that's why mojo annotations and the plugin descriptor exists. I definitively don't want to see us maintaining the metadata for 3rd party plugins.

For this reason, I prefer the original suggestion to introduce a new mojo annotation. Apparently, whatever mojo annotation we come up with, it's not present in any existing plugin release. Now, for plugins missing the threading anno, what is the safer assumption with respect to proper build results: That mojo X is thread-safe (when this was never before a concern) or that it isn't?

IMHO, there's only way to limit this "oh, I deliberately enabled nitro injection and now my engine blew up, how am I supposed to know that this is dangerous?": Unless a mojo is explicitly marked with @threadsafe, issue a warning like

"Goal X does not appear to support concurrent execution and might fail the build, use parallel building at your own risk."


Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to