maven-shade-plugin Add `defaultValue` for all boolean Mojo parameters defaulting to `false`

Currently the Mojo documentation does not mention the default for these parameters, which will be confusing for the user. Have for example a look at the current https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html documentation; you will see that for all the changed parameters no default value is currently documented. So it is not clear whether these parameters apply by default.

Please let me know if I forget to consider something and this change has any undesired side effects.

Following this checklist to help us incorporate your contribution quickly and easily:

[ ] Make sure there is a JIRA issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes.
[x] Each commit in the pull request should have a meaningful subject line and body.
[ ] Format the pull request title like [MSHADE-XXX] - Fixes bug in ApproximateQuantiles, where you replace MSHADE-XXX with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[x] Run mvn clean verify to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.
[x] You have run the integration tests successfully (mvn -Prun-its clean verify).

If your pull request is about ~20 lines of code you don't need to sign an Individual Contributor License Agreement if you are unsure please ask on the developers list.

To make clear that you license your contribution under the Apache License Version 2.0, January 2004 you have to acknowledge this by using the following check-box.

[x] I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004
[ ] In any other case, please file an Apache Individual Contributor License Agreement.

Apr 05 '24 22:04 Marcono1234

Open question: fix pluginxml generation instead of fixing all mojo since it is valid to use the default value for primitives?

May 31 '24 20:05 rmannibucau

That might indeed be a better solution. Can there be cases though were a parameter has a different default value, which is not set with @Parameter(defaultValue = "...")?

For example, if the constructor of a Mojo assigns a value to a field. Does that act as default value then?

Jun 01 '24 19:06 Marcono1234

@Marcono1234 it is possible but will not be in the documentation (requires textual description) but guess the good practise stays to write the less so if default is automatic doc should be aware of it somehow, either ensuring we inject the default for primitives in plugin.xml or let the doc handle it IMHO.

Jun 01 '24 19:06 rmannibucau

doc should be aware of it somehow, either ensuring we inject the default for primitives in plugin.xml or let the doc handle it IMHO

But how do you propose this should be done without being error-prone? Or do you propose to not only improve how the documentation is generated, but also how Maven determines the @Parameter default parameter?

Another case which comes to my mind is:

@Parameter
boolean param = true;

Will the documentation plugin be aware that the default value is true? It would either need to parse the source code or analyze the byte code.

Having the documentation plugin just document false for all @Parameter boolean without defaultValue = "..." would be incorrect it seems.

So yes, maybe this issue could be solved generally for all plugins by doing a change in Maven Plugin Plugin (?). But to me it seems the solution is not simple (if possible at all).

So would you mind accepting this pull request here the way it is for now?

Jun 01 '24 22:06 Marcono1234

The 2 simple options:

Enhance plugin.xml to set defaults for primitives
Enhance doc generation to handle primitives

(I prefer 1 since it will work for all consumers but 2 works for "us")

The inline init case is not supposed to work and it is also hard since init can be conditional (env for ex) so let's ignore coded init and just stick to implicit defaults.

Jun 02 '24 06:06 rmannibucau

The inline init case is not supposed to work

But does it work currently, and are plugins relying on this? Because if Maven Plugin Plugin is changed to pick a different default value in the future in those cases, or if it starts documenting a default value which is not actually the default value, then I doubt that those changes will be made.

Either way, I think this is getting a bit off-topic. Would you mind merging the changes here? Even if Maven Plugin Plugin is changed, that will happen at some point in the future, and until then the Shade plugin documentation would still be incomplete.

If you want the Maven Plugin Plugin to change, could you or someone else please drive those changes, because I am neither familiar enough with Maven internals nor Maven plugin development, and I personally also doubt that such a change would be worth it given the compatibility risks.

Jun 02 '24 20:06 Marcono1234

Some plugings use it but it since it is not static we cant handle it automatically.

I'd prefer to fix the doc and not pollute shade plugin with unexpected code if possible but just my 2cts.

Jun 03 '24 07:06 rmannibucau

@rmannibucau, I had a look at this again, but I still don't see how Maven Plugin Plugin or similar could be enhanced to infer the default value. And suddenly determining a different default value would break existing plugins. See my earlier comment above: https://github.com/apache/maven-shade-plugin/pull/219#issuecomment-2143611680

This pattern of assigning the default value using the field initializer is not that uncommon. Examples:

Jun 30 '24 20:06 Marcono1234

@slachiewicz, would you mind merging these changes?

These changes hopefully help users now (respectively the next Shade Plugin release), whereas some general Maven Plugin Plugin changes (in case they are ever performed, see my concerns above) might only happen after months or years.

Jun 30 '24 20:06 Marcono1234