[
https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844188#comment-17844188
]
Konrad Windszus edited comment on MPLUGIN-522 at 5/7/24 8:08 AM:
-----------------------------------------------------------------
bq. why it gets "highest class version present on classpath"? Why not compiler
target instead?
Because in general it is fair to assume that every class being embedded in the
plugin is supposed to be executed. That requires a Java version capable of
digesting the class version. Not every class being shipped with the plugin is
necessarily compiled in the same build.
bq. if I compile against 3.9.6 Maven APIs, that – due backward compatibility –
does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are
happily working even with 3.6.3 or even 3.2.x.
What you describe is not backwards-compatibility but forwards-compatibility.
Each minor Maven version may add new methods/classes to Maven API in a
backwards-compatible way. Therefore it is fair to assume that the Maven API you
compile against is the minimally required Maven version.
What you are running into are edge cases which IMHO justify that you override
the automatically created values (i.e. one class with bytecode for Java22 not
being executed by the Mojo for some reason, compiling against a newer Maven
version than you require). I don't want plugins to not state prerequisites at
all just because plugin developers are too lazy.
was (Author: kwin):
> why it gets "highest class version present on classpath"? Why not compiler
> target instead?
Because in general it is fair to assume that every class being embedded in the
plugin is supposed to be executed. That requires a Java version capable of
digesting the class version. Not every class being shipped with the plugin is
necessarily compiled in the same build.
> if I compile against 3.9.6 Maven APIs, that – due backward compatibility –
> does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are
> happily working even with 3.6.3 or even 3.2.x.
What you describe is not backwards-compatibility but forwards-compatibility.
Each minor Maven version may add new methods/classes to Maven API in a
backwards-compatible way. Therefore it is fair to assume that the Maven API you
compile against is the minimally required Maven version.
What you are running into are edge cases which IMHO justify that you override
the automatically created values (i.e. one class with bytecode for Java22 not
being executed by the Mojo for some reason, compiling against a newer Maven
version than you require). I don't want plugins to not state prerequisites at
all just because plugin developers are too lazy.
> The auto prerequisites are way to aggressive
> --------------------------------------------
>
> Key: MPLUGIN-522
> URL: https://issues.apache.org/jira/browse/MPLUGIN-522
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
> Reporter: Tamas Cservenak
> Priority: Major
>
> IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong.
> They are way too aggresive and violate backward compatibility: if new feature
> is not explicitly set by user, code should not "come up" with some automatic
> value. By having the value not set simply means user does not want to use it.
> This is especially true for (maven or java) prerequisite, as it creates HARD
> BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto
> user.
> [~kwin]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
