rmannibucau commented on PR #765: URL: https://github.com/apache/maven/pull/765#issuecomment-1182963000
Ok so let me step back: 1. Goal is to ensure defined plugins are compatible with the maven version 2. Technically you cannot use maven-plugin API test like that to implement it, you need to ensure the API *used* by the plugin is available in current maven version Since we care only about maven 4 there - guess for maven 3 the game is already played - we should probably add these metadata somewhere in 1. maven and 2. plugins (at build time with maven-plugin-plugin probably), this way the check is not a version check which is very error prone but an accurate check. This means apache/maven build would dump a txt file in its resources with the supported plugin API and mojo would have in its own resources a META-INF/maven/whataver/used-api.txt. Comparing both we would get the compatibility for sure. One trick can be to be able to configure a bit more this dump to enable optional parts of the mojo to be marked as being optional and theorically activated by this or this configuration (if <git> is not null class GitWhatever is used so the mojo api used in this class is needed in the validation for ex). But until we have such a mecanism (computed build time so fast or at runtime with bytecode visiting - slower) then any work in that direction sounds like noise for end user. Now the side note stays, it shouldn't be something enabled for all runs but only when user requests it, this is why I think it belongs to a plugin (versions was a good one but any other would work for me) and not maven core. Also note that it is not very complicated for a plugin to validates its maven API dependencies when it is instantiated (loadClass, getMethod are more than sufficient) so it can just be about encouraging that. Hope it is clearer. Just to answer to your questions: > AFAIK if you use maven 2 and the same surfacing API than with 3.1 then you don't want this warning Means that the version is not a key point since maven 2 API and maven 3 overlap enough to have functional plugin with maven 2 so we must not warn for them. > What about using this slower but more accurate implementation in versions-maven-plugin? Was just referencing the bytecode based implementation, nothing linked to lifecycles. -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
