I think the main problem is that "maven-core" is often rejecting request
for providing useful things in the first place.
That leads to all kind of "helper", "util", ... so maybe instead of
having a maven-core-plugin, it would better to have a maven-plugin-core
module (what of course can for example contain things like
AbstractXXXMojo others can extend.
Then one can easily share (and improve) common code but still has the
mentioned advantage of individual releases/plugins and flexibility.
Am 15.08.24 um 13:35 schrieb Konrad Windszus:
Hi,
Although I do see the benefits from a Maven Dev perspective for Consumers this
is worse.
In the past often individual plugin versions suffered from regressions for
certain edge cases.
Having individual separate plugins allowed consumers to deliberately use an old
version of one plugin (e.g. maven-resources-plugin) while upgrading all others
to the latest version available.
One example is maven-resources-plugin which suffered from some regressions in
the past.
Instead I would rather try to identify the shared code and put it into a
library (new or existing).
Konrad
On 15. Aug 2024, at 13:13, Tamás Cservenák <ta...@cservenak.net> wrote:
Howdy,
as am going over multiple plugins (as it is time to upgrade parent, some
bugfix, etc), all I see is:
* a LOT of code duplication across plugins (some even have comments like in
plugin X "this should be shared with Y")
* some "forcefully" pushed out "shared" artifact to share them across
* just many too small codebases that needs a LOT of process/work effort for
small gain
* it is all chopped up into relatively small pieces
Hence, we were already discussing this idea on Slack: what if we introduce
maven-core-plugin?
One single plugin that contains some "most common" Mojos?
(nothing new under Sun, this would be the "a la Takari Lifecycle"
situation, where one plugin delivers most common Mojos -- although there
the incentive was build avoidance/incremental build).
For start, we could consider all 'core' plugins (those referenced from
maven like in lifecycle mapping) except:
* m-compiler-p
* m-surefire-p
as they are complex on their own.
WDYT?
Tamas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
