Repository navigation
[MPLUGIN-530] Deprecate requirements in plugin descriptor 1.1.0 - #1638
Conversation
|
@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. |
|
Does that mean the plugin descriptors for v4 should no longer contain those? |
It doesn't afaik. |
|
v4 is using plugin descriptor 2.0. Having |
|
So if you're targeting master, I'm not sure this PR is really needed. @kwin wdyt ? |
|
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. |
We are somehow going in cycles with this PR: Regarding
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.
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! |
2235e28 to
6e6f0dc
Compare
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.
If you consider the XML the API, you can't bind to the implementation. Why are we talking about JSR330 annotations or
It's fine to add the deprecation to the 1.1 model imho. Both 1.1 and 2.0 are supported by Maven 4. |
6e6f0dc to
40a3231
Compare
The replacement for v4 plugins should be Maven DI annotations while for v3 plugins it is JSR 330 annotations
40a3231 to
775c5df
Compare
gnodet
left a comment
gnodet
left a comment
There was a problem hiding this comment.
LGTM. However, this won't appear anymore, because we don't generate the 1.1.0 schema.
|
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. |
3 participants
It is already removed for 2.0.0
Following this checklist to help us incorporate your
contribution quickly and easily:
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.
[MNG-XXX] SUMMARY,where you replace
MNG-XXXandSUMMARYwith the appropriate JIRA issue.[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.
mvn clean verifyto make sure basic checks pass. A more thorough check willbe performed on your pull request automatically.
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.