> On 18. Aug 2024, at 12:59, Hervé Boutemy <herve.bout...@free.fr> wrote:
>
> with Maven 4, we'll have to maintain a 4.x branch of each plugin in parallel
> to the current Maven 3 compatible one: Maven 4 is the right time to have the
> discussion and eventually change the structure
>
> we need to clarify what "core" means:
>
> from https://maven.apache.org/plugins/ , I suppose we would try to merge
> clean
> (1 goal), deploy (2 goals), install (2 goals) and resources (3 goals) into a
> new plugin (8 goals)?
> Any other existing plugin that you think would be candidate to the merge?
> Any "LOT of code duplication" that is found elsewhere?
>
>
> on evaluating the value we get from it:
> as a Maven dev, it's true that clean, install and deploy have few releases.
> Resources seem to have a current issue reported by Konrad, I need to
> understand...
>
This is no longer true in the newest m-resource-p, it was just an example where
I could not upgrade m-resource-p to a newer version due to a regression.
That would no longer be possible if all goals would be part of one common
plugin (because then it is all or nothing for those mojos).
> as a user, it's true that these plugins are used in each and every packaging
> bindings https://maven.apache.org/ref/3.9.9/maven-core/default-bindings.html
> ,
> having only one version to drive them would be nice
>
> Regards,
>
> Hervé
>
>
> Le jeudi 15 août 2024, 13:13:57 CEST Tamás Cservenák a écrit :
>> 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
