[jira] [Comment Edited] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844188#comment-17844188 ] Konrad Windszus edited comment on MPLUGIN-522 at 5/7/24 8:18 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. Similarly, if I have one class that is Java 22, the plugin prerequisite is NOT Java 22. It the class is in the plugin classpath I would assume that this is necessary for plugin execution (not necessarily for each mojo). If the class isn't being called then it shouldn't be there in the first place... 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, because that is very frustrating for users not complying with those (unexplicit) prerequisites. was (Author: kwin): 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, because that is very frustrating for users not complying with those (unexplicit) prerequisites. > 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)
[jira] [Comment Edited] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844195#comment-17844195 ] Tamas Cservenak edited comment on MPLUGIN-522 at 5/7/24 8:14 AM: - Also, your statement is wrong: toolbox plugin does NOT have Java 22 class "in plugin". It has it in among dependencies, not the same (and is not even user-controlled). was (Author: cstamas): Also, your statement is wrong: toolbox plugin does NOT have Java 22 "in plugin". It has it in among dependencies, not the same (and is not even user-controlled). > 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)
[jira] [Comment Edited] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844188#comment-17844188 ] Konrad Windszus edited comment on MPLUGIN-522 at 5/7/24 8:10 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, because that is very frustrating for users not complying with those (unexplicit) prerequisites. was (Author: kwin): 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. > 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)
[jira] [Comment Edited] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Comment Edited] (MPLUGIN-522) The auto prerequisites are way to aggressive
[
https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843885#comment-17843885
]
Tamas Cservenak edited comment on MPLUGIN-522 at 5/7/24 8:07 AM:
-
Example: try with Maven4 + Java 21: {{mvn
eu.maveniverse.maven.plugins:toolbox:tree}} and it will explode, claiming
"plugin requires Java 22". Now use Java 11 and Maven 3.6.3, and plugin works!
was (Author: cstamas):
Example: try with Maven4 + Java 21: {{mvn
eu.maveniverse.maven.plugins:toolbox:tree}} and it will explode, claiming
"plugin requires Java 22". Now use Java 11 and Maven 3.9.6, and plugin works!
> 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)
[jira] [Comment Edited] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843886#comment-17843886 ] Tamas Cservenak edited comment on MPLUGIN-522 at 5/6/24 9:01 PM: - IMHO, any prerequisite should be added ONLY if explicitly specified. The two issues altered (in a wrong way) behaviour of m-p-p: they are ALWAYS added, and worse, the "auto" values are magically (and completely wrongly) calculated: 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. Similarly, if I have one class that is Java 22, the plugin prerequisite is NOT Java 22. Both things should be reverted to original behaviour: added IF user specified them, otherwise omitted (instead of "auto calculate" them). was (Author: cstamas): IMHO, any prerequisite should be added ONLY if explicitly specified. The two issues altered (in a wrong way) behaviour of m-p-p: they are ALWAYS added, and worse, the "auto" values are magically (and completely wrongly) calculated: 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. Similarly, if I have one class that is Java 22, the plugin prerequisite is NOT Java 22. > 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)
