gnodet commented on code in PR #117:
URL: 
https://github.com/apache/maven-plugin-tools/pull/117#discussion_r1001432305


##########
maven-plugin-tools-annotations/src/main/java/org/apache/maven/tools/plugin/extractor/annotations/scanner/MojoAnnotationsScanner.java:
##########
@@ -37,13 +37,21 @@
 {
     String ROLE = MojoAnnotationsScanner.class.getName();
 
+    String V4_API_PLUGIN_PACKAGE = "org.apache.maven.api.plugin";

Review Comment:
   > Maybe a bit late but why are the annotations part of maven-api-core? IMHO 
those are used exclusively at build time (not at run time) by m-plugin-tools 
only to build the descriptor, so why defining them globally?
   
   The plugin annotations are the first classes needed for people that consume 
the maven api.  It's part of the API and I would not consider the fact that 
they are only used at build time (that's an implementation detail of how plugin 
works).  That is also related to the fact that the `MojoDescriptor` is 
currently not exposed in the api.  So there's a small change in semantics, as I 
consider the annotations as _the api_ for plugin authors, while the descriptor 
is kept an implementation detail (which is good imho as it inherit plexus 
classes which should be hidden).
   Some attempts have been made over the years to define plugins in other 
languages such as the scripting stuff, but it's being deprecated and will be 
removed soon I think.  I think that's an indication that (nearly) all plugins 
are simply written using the provided annotations, so they _de facto_ 
constitute the mojo API.
   
   > Also why can't the old annotations be extended with just that a boolean 
flag for v4Api?
   
   They could.  But for the reason above, I think they should belong to the 
"_maven api_" which I think is best kept in a single location rather than 
splitted across various modules and projects.  Now, people can simply depend on 
the `maven-api-core` jar and have a clear view of all the maven api they can 
use.



-- 
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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to