Le lundi 19 août 2024, 09:43:50 CEST Christoph Läubrich a écrit :
> Should it really be "core-plugin" or can't one simply retain existing
> plugin names.
sorry, a plugin has a single name, no per-goal customization: merging plugins
means from a user perspective using one single new plugin name
Of
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 m
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 c
Le dimanche 18 août 2024, 13:04:39 CEST Konrad Windszus a écrit :
> > On 18. Aug 2024, at 12:59, Hervé Boutemy 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 discussio
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
wrote:
> Putting all plugin
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 wrote:
>
> As a maven user, I agree with Konrad on the fact that putting all plugin
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 a
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 wrote:
>
>
> > On 18. Aug 2024, at 12:59, Hervé Boutemy wrote:
> >
> > with
> On 18. Aug 2024, at 12:59, Hervé Boutemy 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 "cor
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 wo
Having N module in a single repo is not a game changer in terms of releases
IMHO, if so our tooling is bad and can be enhanced so only question is all
in a single plugins (monoproject/module) or nothing, no?
Le sam. 17 août 2024 à 10:30, Christoph Läubrich a
écrit :
> Just wanted to mention that
Just wanted to mention that even if many project/modules/... are in the
same git-repository (and probably having a "common" code) does not mean
one can't deploy/build/... them individually.
Am 17.08.24 um 09:39 schrieb Olivier Lamy:
Hi
Not sure to understand the structure of this and the rel
Hi
Not sure to understand the structure of this and the release cycle and if
this includes maintenance of maven3 branches of plugins.
If I understand correctly when cutting a release we will cut a release of
every plugins?
On Fri, 16 Aug 2024 at 10:00 PM, Ozgun Oz wrote:
> Just an outsider here,
Hey,
as I see a lot of improvements and (ofc after the initial time effort of
the set up) time savings in the future (by not writing the same multiple
times but also to avoid introducing manual issues when you do the same
for th x times, but always a slightly different cause of the slightly
diffe
Just an outsider here, but I agree with Guillaume. Also I think Tamas'
proposal is to merge the existing plugins, so the repo of the old plugins
will be probably archived and the old plugins code will be moved to the new
plugin repo.
Since the old plugins will not evolve and maintained by ASF, and
Well this would be the same plugins, not duplicates….
Guillaume Nodet
Le jeu. 15 août 2024 à 20:10, Elliotte Rusty Harold a
écrit :
> On Thu, Aug 15, 2024 at 1:24 PM Delany wrote:
>
> > The $5000 question is how can the old plugins still even exist if the
> code
> >
On Thu, Aug 15, 2024 at 1:24 PM Delany wrote:
> The $5000 question is how can the old plugins still even exist if the code
> for them has been moved to a new core plugin?
In the git repo. In Maven central. In absolutely every existing plugin
and build that depends on these today. They aren't go
Just to be clear, your argument seems to be that a new plugin must always
add new functionality,
not that its existence should make its ancestors obsolete
(since by that measure Ubuntu has failed since Debian still exists)
But still, the xkcd comic is about *competing* standards (A/C adaptors,
cha
No, it seems to be a proposal for a new core plugin, not just
reorganzing the git repo. I predict if someone tries that we'll still
have all the old plugins plus the new maven-core-plugin. I have seen
this play out so many times over the years. Another old favorite:
https://www.youtube.com/watch?
Yes, I don’t understand either.
I think the proposal is just to merge all core plugins into a single
project.
Guillaume Nodet
Le jeu. 15 août 2024 à 16:39, Tamás Cservenák a
écrit :
> Eliotte,
>
> Who would "compete" within the ASF Maven project?
>
> T
>
> On Thu, Aug
AFAIK, Tamas suggested to *move* all plugins in a single maven-core-plugin,
not to extract reusable data in a new git repo.
Le jeu. 15 août 2024 à 15:42, Christoph Läubrich a
écrit :
>
> I think the main problem is that "maven-core" is often rejecting request
> for providing useful things in the
Think we should either assume it and make these plugins embedded in core
(same loader) or just let it like that and if needed extract reusable
services in core when dep free.
Le jeu. 15 août 2024 à 16:39, Tamás Cservenák a
écrit :
> Eliotte,
>
> Who would "compete" within the ASF Maven project?
Eliotte,
Who would "compete" within the ASF Maven project?
T
On Thu, Aug 15, 2024 at 4:37 PM Elliotte Rusty Harold
wrote:
> This sounds like an opportunity to cite my all-time favorite xkcd:
>
> https://xkcd.com/927/
>
> On Thu, Aug 15, 2024 at 7:15 AM Tamás Cservenák
> wrote:
> >
> > Howdy,
This sounds like an opportunity to cite my all-time favorite xkcd:
https://xkcd.com/927/
On Thu, Aug 15, 2024 at 7:15 AM Tamás Cservenák 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 acro
Is this proposal because elements from the super pom has been removed from
4.x?
https://issues.apache.org/jira/browse/MNG-6054
https://maven.apache.org/ref/3.9.8/maven-model-builder/super-pom.html
https://maven.apache.org/ref/4.0.0-alpha-9/maven-model-builder/super-pom.html
Which changes a new use
For me, if it's only dependency updates or matching versions of sibling
jars, it's a valuable new release because it says "We _know_ 100% this
combination works". Assuming the combination is tested.
Gary
On Thu, Aug 15, 2024, 9:01 AM Guillaume Nodet wrote:
> I would think the benefit of having
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 ex
I would think the benefit of having a single plugin would be to have faster
release cycles, as the amount of work for a single release is quite
important imho. So having a single release cycle would lower the ration
work/ nb mojos.
That said, I think that could also be achieved by using a reactor
As an outsider I would welcome that especially if it (1) made it simpler to
write new plug-ins and/or (2) I would get new features or bug fixes "for
free" if my plug-ins reused the right superclass or class.
2c,
Gary
On Thu, Aug 15, 2024, 7:15 AM Tamás Cservenák wrote:
> Howdy,
>
> as am going
The concrete example I suffered from was
https://issues.apache.org/jira/browse/MRESOURCES-289 which forced me to stay on
3.1.0
(https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/58ef9f5f28d8e54c4d26d35011b1caff570a1b1d/pom.xml#L111-L115).
> On 15. Aug 2024, at 13:35, Konr
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
31 matches
Mail list logo
