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. Bur 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]