Le dimanche 18 août 2024, 13:04:39 CEST Konrad Windszus a écrit :
> > 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).

ok, good news
that's why the new "core" plugin requires a reasonable goals scope, as any 
other plugin: a plugin with more than 10 goals in general tends to be hard to 
simply document, like we have experience with dependency plugin for example

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





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to