[MPLUGIN-530] Deprecate requirements in plugin descriptor 1.1.0

[kwin]

It is already removed for 2.0.0

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.
• Each commit in the pull request should have a meaningful subject line and body.
• Format the pull request title like [MNG-XXX] SUMMARY,
  where you replace MNG-XXX and SUMMARY with the appropriate JIRA issue.
• Also format the first line of the commit message like [MNG-XXX] SUMMARY.
  Best practice is to use the JIRA issue title in both the pull request title and in the first line of the commit message.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Run mvn clean verify to make sure basic checks pass. A more thorough check will
  be performed on your pull request automatically.
• You have run the Core IT successfully.

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.

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

[kwin]

@gnodet Have you deliberately removed that from the plugin descriptor 2.0.0? It is still written in https://github.com/apache/maven-plugin-tools/blob/9332b09acc08d2e063f12a8158a57ca8ec56fadd/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorFilesGenerator.java#L593 (even for V4/2.0.0)

[gnodet]

@gnodet Have you deliberately removed that from the plugin descriptor 2.0.0? It is still written in https://github.com/apache/maven-plugin-tools/blob/9332b09acc08d2e063f12a8158a57ca8ec56fadd/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorFilesGenerator.java#L593 (even for V4/2.0.0)

The injection mechanism is different for V4 mojo as it uses the new DI API / implementation.

[kwin]

Does that mean the plugin descriptors for v4 should no longer contain those?

[gnodet]

Does that mean the plugin descriptors for v4 should no longer contain those?

It doesn't afaik.
See https://github.com/apache/maven/blob/master/api/maven-api-plugin/src/main/mdo/plugin.mdo#L411 and https://github.com/apache/maven/blob/master/api/maven-api-plugin/src/main/mdo/plugin.mdo#L411

[kwin]

v4 is using plugin descriptor 2.0. Having requirements only for version 1.0 and 1.1 makes it disappear in 2.0 (just look at the generated doc from modello). If it is still relevant it should have version 1.0+

[gnodet]

So if you're targeting master, I'm not sure this PR is really needed. @kwin wdyt ?

[cstamas]

Same question here: IF this goes to master, the deprecation message is plain wrong (mvn4 API has DI annotation, and not JSR330 is to be used). Am unsure is this PR really needed.

[kwin]

So if you're targeting master, I'm not sure this PR is really needed.

We are somehow going in cycles with this PR:
@gnodet I think we agreed that even for Plugin Descriptor v2 the requirements is still evaluated! That means it should be marked as deprecated in both 1.1 and 2.0! I am gonna fix the version in this PR as well for requirements, but you should go over all other elements as well!

Regarding

the deprecation message is plain wrong (mvn4 API has DI annotation, and not JSR330 is to be used)

I am gonna clarify that in the deprecation that this is not necessarily JSR 330 annotation but alternatively some other annotation evaluated at run time.

Am unsure is this PR really needed.

For me the plugin descriptor is the primary contract between a plugin and Maven, and therefore it needs to be formally deprecated there before we can ultimately get rid of it in the future!

[gnodet]

So if you're targeting master, I'm not sure this PR is really needed.

We are somehow going in cycles with this PR: @gnodet I think we agreed that even for Plugin Descriptor v2 the requirements is still evaluated! That means it should be marked as deprecated in both 1.1 and 2.0! I am gonna fix the version in this PR as well for requirements, but you should go over all other elements as well!

As you've found out, it's not in the generated xml schema for v2.

I don't see how it could be supported with the v2 schema without removing the DI support and restoring plexus.

Regarding

the deprecation message is plain wrong (mvn4 API has DI annotation, and not JSR330 is to be used)

I am gonna clarify that in the deprecation that this is not necessarily JSR 330 annotation but alternatively some other annotation evaluated at run time.

If you consider the XML the API, you can't bind to the implementation. Why are we talking about JSR330 annotations or @Component if that's the case ?

Am unsure is this PR really needed.

For me the plugin descriptor is the primary contract between a plugin and Maven, and therefore it needs to be formally deprecated there before we can ultimately get rid of it in the future!

It's fine to add the deprecation to the 1.1 model imho. Both 1.1 and 2.0 are supported by Maven 4.

[gnodet]

LGTM. However, this won't appear anymore, because we don't generate the 1.1.0 schema.

[kwin]

I plan to backport to 3.x and publish it, because there were also some other changes being supported meanwhile in Maven 3.x. I don't think this causes any harm here. Later on we can remove all outdated elements from the MDO in master.

[gnodet]

I plan to backport to 3.x and publish it, because there were also some other changes being supported meanwhile in Maven 3.x. I don't think this causes any harm here. Later on we can remove all outdated elements from the MDO in master.

They are part of modello support for history. We do actually use the same MDO in two different versions to generate the v3 and v4 model classes. I agree this is not used for plugins, but I don't see the point of removing those.