[MPLUGIN-522] The auto prerequisites are way too aggressive

[jira-importer]

Tamas Cservenak opened MPLUGIN-522 and commented

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.

Konrad Windszus 

---

Issue Links:

• MPLUGIN-523 Split Maven3 and Maven4 support
  ("is blocked by")
• MNG-7566 Allow a Maven plugin to require a Java version through its plugin descriptor
  ("is caused by")
• MPLUGIN-425 Plugin descriptor should contain the requiredJavaVersion/requiredMavenVersion
  ("is caused by")

Remote Links:

• GitHub Pull Request #282
  

[jira-importer]

Tamas Cservenak commented

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!

[jira-importer]

Tamas Cservenak commented

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).

[jira-importer]

Tamas Cservenak commented

For example the java prerequisite: why it gets "highest class version present on classpath"? Why not compiler target instead?

For Maven prerequisite: you cannot infer Maven prerequisite based on API you compile against. As mentioned, even if I compile against latest (3.9.6), the plugin may just fine work with 3.6.3 as well.

Hence, these two should be and remain (as before) opt in values. We cannot "deduce" what user wants, it is up to user to tell us what he wants.

[jira-importer]

Konrad Windszus commented

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.

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

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.

[jira-importer]

Tamas Cservenak commented

In that case just fail the build (like we did with prefix). You cannot auto deduce developer intent, as example shows, it happens in a wrong way.

[jira-importer]

Tamas Cservenak commented

Currently m-p-p produces plugins:

• that happily works on Java 11 w/ Maven 3.6.3
• but fails with Maven 4 (that observe these new entries in plugin descriptor) due fals prerequisites: it claims it needs Java 22 and Maven 3.9.6, and none of these are true

I, as a developer was totally oblivious of these auto-set values, until i tried the plugin with Maven4.

[jira-importer]

Tamas Cservenak commented

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).

[jira-importer]

Michael Osipov commented

Tamas Cservenak, do you want to pick this up for 3.14.0 mid of August?