Should it really be "core-plugin" or can't one simply retain existing
plugin names.
I'm just asking because:
1) It would invalidate each and every custom configuration / executions
2) All share the same "configuration space" then
3) A prefix can only be applied once for a plugin but not for a mojo
(afaik) so also cli invocations will be broken / maybe unexpected
Am 19.08.24 um 09:04 schrieb Hervé Boutemy:
back to: we need to clarify what scope of merge is expected
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 "core" 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?
if we don't clarify or precise expected scope by different people, the
discussion is getting into circles: https://maven.apache.org/plugins/ lists 52
plugins, I hope nobody expects to merge much
Regards,
Hervé
Le dimanche 18 août 2024, 15:27:05 CEST Gary Gregory a écrit :
I also wonder why the core needs to be sliced and diced at this level of
plugin granularity. I imagine some of ot is for historical reasons. My
comments are just born out of curiosity, this is not a criticism 😀
Gary
On Sun, Aug 18, 2024, 9:19 AM Elliotte Rusty Harold <elh...@ibiblio.org>
wrote:
Putting all plugins in a single plugin jar also makes releases more
challenging. 9 plugins might not be able to be updated because of a
critical regression in one of them.
On Sun, Aug 18, 2024 at 12:49 PM Ozgun Oz <ozgunn...@gmail.com> wrote:
As a maven user, I agree with Konrad on the fact that putting all
plugins
in a single plugin jar will remove the flexibility users have today to
uprade them independently in case of bug/regression/retrocompability
issue
in one plugin.
Why not creating a library that regroups the duplicated code among
plugins ?
On Sun, Aug 18, 2024, 2:34 PM Gary Gregory <garydgreg...@gmail.com>
wrote:
Another way to look at a "core":
In my Maven 3.9.8 install folder I have 23 "maven-" jars including 10
"maven-resolver-". Why don't I just a single "maven-core" jar?
Gary
On Sun, Aug 18, 2024, 7:04 AM Konrad Windszus <k...@apache.org> wrote:
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
--
Elliotte Rusty Harold
elh...@ibiblio.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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
