This is slightly differently described on https://maven.apache.org/plugins/
Core plugins Plugins corresponding to default core phases (ie. clean, compile). They may have multiple goals as well. But I think the intention is clear: This should apply to all plugins maintained by the Apache Maven Project (not only core plugin according to the definition from above). Konrad > On 6. Mar 2024, at 15:12, Tamás Cservenák <ta...@cservenak.net> wrote: > > Gary, > > maven "core plugins" are these > https://maven.apache.org/plugins/ > > In short, Maven plugins that are maintained by this project at ASF. > > While there is a quite overlap with mojohaus etc, they are NOT core plugins > > T > > On Wed, Mar 6, 2024 at 3:09 PM Gary Gregory <garydgreg...@gmail.com> wrote: > >> One issue from a non-Maven dev (me) is that I have no idea what is a >> Maven "core" plugin vs. not. I would make that obvious for users, and >> no, the "maven-" prefix does not make it obvious: >> >> maven-clean-plugin -> maven-core-clean-plugin or maven4-core-clean-plugin >> >> I'm also not sure the "plugin" suffix is needed: >> >> maven-clean-plugin -> maven-core-clean or maven4-core-clean >> >> My preference is "maven4-core-clean" >> >> Gary >> >> On Wed, Mar 6, 2024 at 8:59 AM Tamás Cservenák <ta...@cservenak.net> >> wrote: >>> >>> Howdy, >>> >>> We have several topics that need to be discussed. >>> >>> I. Core Plugin Versioning >>> >>> History: When Maven2 was born, and started using plugins "as we know them >>> today" (Maven 1 was a very different beast), the Core Plugin versions >> were >>> started as 2.0 on purpose. Just check the Maven Central for historical >>> versions, some examples: >>> * clean >>> >> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/ >>> * compiler >>> >> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/ >>> * jar >>> >> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/ >>> * surefire >>> >> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/ >>> * dependency >>> >> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/ >>> >>> So, Maven2 "as a fresh release" got all new shiny 2.0 plugins at the >>> beginning. Later on, when Maven3 came to existence, it was able to use >>> Maven2 plugins, the plugins were slowly migrated to become "Maven 3 >>> plugins" (Maven2 could not use them anymore). This was denoted by the >> "3.x" >>> major plugin version jump. >>> >>> So far, we have no 4.x plugin release of anything (M releases do not >>> count). But my question is the following: >>> >>> How should we distinguish similar changes for Maven4? >>> >>> Explanation: when a plugin is migrated to Maven4 API, it will mean Maven3 >>> will NOT be able to use anymore (will be incompatible). Similarly as >>> before, Maven4 CAN run the "Maven 3" plugins, and will retain this >>> capability for some time. But other ways it does not work, nor never >> worked >>> (Maven3 will not be able to run Maven4 plugin, just like Maven2 never ran >>> Maven3 plugin). >>> >>> For me, the logical answer to this question is the use of major version >>> 4.x. So just like it happened with Maven 2 to Maven 3 transition, a >> plugin >>> version 2.x meant "Maven2 plugin", version 3.x of plugin meant "Maven3 >>> plugin" (Maven2 incompatible). >>> >>> As otherwise, if we start releasing Core plugins 4.x or 5.x, we will >>> confuse the hell out of our users. At least that is what I think. >>> >>> II. Consequence: How to interpret Core plugin versions >>> >>> As can be seen above, so far the major version of the plugin was kinda >>> showing "which Maven API level" is the plugin. >>> >>> So, it begs the question: HOW to interpret the Maven Core Plugin version? >>> >>> My interpretation was always: "shift it once left", meaning: Core plugin >>> version "3.2.1" MEANS: >>> - Maven API version: 3 >>> - Core Plugin version 2.1(.0) >>> >>> III. Consequence: How to express Core plugin "breaking change"? >>> >>> Today, everyone expects a "major version jump" to express breaking >> changes. >>> BUT, as explained above, that would be totally misleading here, and would >>> break the "customary law" that Major expresses Maven lineage. >>> >>> Ideas and opinions welcome. >>> >>> T >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >>
