Re: Release soon of Maven Build cache 1.2.0

[Kévin Buntrock]

Looks good to me. ;)

Thank you by advance.

Kind regards,
Kevin

Le ven. 3 mai 2024, 05:40, Olivier Lamy  a écrit :

> Hi,
> A couple of new features and fixes have been contributed.
> I would like to release this maybe next week.
> Probably randomly between Monday and Sunday (yeah, that's a enough
> time window to give me some time)
>
> If any concerns please let me know.
>
> cheers
> Olivier
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] MDK, a Maven Plugin SPI example

[Romain Manni-Bucau]

Well not sure what you didn't get from my mails but

1. I agree current solution does not need anything new if it was ambiguous
2. the mail you reference was for jreleaser outside maven so out of topic
there IMHO

If MDK does not need an external SPI I agree with you there is no new
concept nor need of any maven thread since we don't change anything ;)

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 6 mai 2024 à 21:02, Tamás Cservenák  a écrit :

> >
> >
> > Well, for *existing* core component I don't see an issue to add a toggle
> to
> > say "deploy at end".
> > What can be an issue there is only to make it global for the session and
> > not per artifact + how to define "end" - agree onSessionClose can be too
> > late but sure we can find a good "phase" (plain english not maven
> phases).
> >
>
> Which *existing* core component deploys today in Maven?
> "At Maven Session end" (and no errors happened) is pretty good plain
> english for me.
>
>
> >
> > I understand you only talk about artifact but makes years it is no more
> > what maven trigger as deployment and we don't have much issue with
> current
> > solution but we have with combined ones and making it using a different
> > lifecycle will make it even harder to handle, in particular with shared
> > components where lifecycle is no more what is in the pom and therefore
> you
> > don't control it properly anymore from the pom.
> > Feels like regressing 10 years ago in terms of solution covering for me.
> >
>
> Nobody mentioned a different lifecycle, only you.
> MDK is totally the opposite of what you write...
> Current m-deploy-p solution (the one you consider "good") is unchanged
> since Maven 2.x, so unsure what regressing you talk about.
> To be precise, is unchanged since 18 years, so 10 years sounds quite good,
> no? (a joke)
>
>
> > I have no idea what you target with your block about sonatype, users are
> > covered by sonatype (both solutions btw at the cost of some jvm.config
> and
> > deps for the oldest).
> >
>
> Does not sound to me like what you say stands:
> https://lists.apache.org/thread/6t95xpkgjpxooljf613xf1853qrfv7yq
>
> I don't feel "covered", sorry. Also, remember that (old) nx-staging-m-p
> already broke once in Maven 3.9.x span.
>
>
> > To be honest, today - and I never said it will not change ;), I don't
> care
> > much of MDK but more about adding a concept we don't need and which will
> > create new issues in maven so let's try to use one of the existing
> > solutions maybe before moving to building a new maven - or discuss
> > rebuilding maven from scratch if that is the ultimate intent, if we break
> > the compat rule a lot of things can change and concepts can be
> > simplified+refined but AFAIK we are not in this mood, are we?
> >
> >
> You do it again: which "new concept" is added exactly by MDK?
> (as everything else works based on existing and proven patterns).
>
> T
>

Re: [DISCUSS] MDK, a Maven Plugin SPI example

[Tamás Cservenák]

>
>
> Well, for *existing* core component I don't see an issue to add a toggle to
> say "deploy at end".
> What can be an issue there is only to make it global for the session and
> not per artifact + how to define "end" - agree onSessionClose can be too
> late but sure we can find a good "phase" (plain english not maven phases).
>

Which *existing* core component deploys today in Maven?
"At Maven Session end" (and no errors happened) is pretty good plain
english for me.


>
> I understand you only talk about artifact but makes years it is no more
> what maven trigger as deployment and we don't have much issue with current
> solution but we have with combined ones and making it using a different
> lifecycle will make it even harder to handle, in particular with shared
> components where lifecycle is no more what is in the pom and therefore you
> don't control it properly anymore from the pom.
> Feels like regressing 10 years ago in terms of solution covering for me.
>

Nobody mentioned a different lifecycle, only you.
MDK is totally the opposite of what you write...
Current m-deploy-p solution (the one you consider "good") is unchanged
since Maven 2.x, so unsure what regressing you talk about.
To be precise, is unchanged since 18 years, so 10 years sounds quite good,
no? (a joke)


> I have no idea what you target with your block about sonatype, users are
> covered by sonatype (both solutions btw at the cost of some jvm.config and
> deps for the oldest).
>

Does not sound to me like what you say stands:
https://lists.apache.org/thread/6t95xpkgjpxooljf613xf1853qrfv7yq

I don't feel "covered", sorry. Also, remember that (old) nx-staging-m-p
already broke once in Maven 3.9.x span.


> To be honest, today - and I never said it will not change ;), I don't care
> much of MDK but more about adding a concept we don't need and which will
> create new issues in maven so let's try to use one of the existing
> solutions maybe before moving to building a new maven - or discuss
> rebuilding maven from scratch if that is the ultimate intent, if we break
> the compat rule a lot of things can change and concepts can be
> simplified+refined but AFAIK we are not in this mood, are we?
>
>
You do it again: which "new concept" is added exactly by MDK?
(as everything else works based on existing and proven patterns).

T

Re: [DISCUSS] MDK, a Maven Plugin SPI example

[Romain Manni-Bucau]

Well, for *existing* core component I don't see an issue to add a toggle to
say "deploy at end".
What can be an issue there is only to make it global for the session and
not per artifact + how to define "end" - agree onSessionClose can be too
late but sure we can find a good "phase" (plain english not maven phases).

I understand you only talk about artifact but makes years it is no more
what maven trigger as deployment and we don't have much issue with current
solution but we have with combined ones and making it using a different
lifecycle will make it even harder to handle, in particular with shared
components where lifecycle is no more what is in the pom and therefore you
don't control it properly anymore from the pom.
Feels like regressing 10 years ago in terms of solution covering for me.

I have no idea what you target with your block about sonatype, users are
covered by sonatype (both solutions btw at the cost of some jvm.config and
deps for the oldest).

To be honest, today - and I never said it will not change ;), I don't care
much of MDK but more about adding a concept we don't need and which will
create new issues in maven so let's try to use one of the existing
solutions maybe before moving to building a new maven - or discuss
rebuilding maven from scratch if that is the ultimate intent, if we break
the compat rule a lot of things can change and concepts can be
simplified+refined but AFAIK we are not in this mood, are we?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 6 mai 2024 à 20:41, Tamás Cservenák  a écrit :

> And few more things:
> - my intent is to target BOTH, Maven3 and Maven4, as when Sonatype
> deprecates OSS/S01 in favor of Central Portal, Maven3 (and currently also
> Maven4) users are doomed to "roll their own" solutions for Central
> publishing. While Sonatype Nx2 (running on Sonatype OSS/S01 and ASF repo)
> can work to a certain degree with m-deploy-p (at the "cost" of logging in
> to the UI, and pressing Close button on auto-created staging repository),
> the new Central Portal will not work with it (as it seems from doco). IMHO,
> we cannot leave Maven3 users behind, we cannot afford to leave Maven3 users
> without any solution.
> - MDK like solution could also provide support in cases like this (my next
> task on radar):
> https://lists.apache.org/thread/j3r4hvoonx6ftl8vlgs0fo4f2z9pmll5
> - and finally, nothing forces you to use MDK, obviously. If you publish OCI
> images or beam up little green people with Maven, you do not have to use
> it! Solution is opt-in, that IS one of the key points of MDK :)
>
> But to have ANY progress on ANY of this:
> - the plugin SPIs needs to be created/released
> - we need to use SPIs in plugins
> - and only then we can provide seamless experience to our users
>
>
> T
>
>
> On Mon, May 6, 2024 at 8:24 PM Tamás Cservenák 
> wrote:
>
> >
> >> If you don't need to create a new module nor any new interface in maven
> >> core or a shared module I'm all for the change, otherwise it is a new
> >> shared thing whatever you present it.
> >>
> >
> > So, if we don't change anything, you accept the "change"? :)
> >
> > In short: MDK is just a "tech demo", but the "real stuff" is:
> > * introduce SPIs for targeted o.a.m.p plugins (the proposed ones are
> > deploy and gpg plugins)
> > * modify o.a.m.p plugins to use SPI pattern (again, m-deploy-p and
> m-gpg-p)
> > * and from that moment on, we have an "open for all" game in play, as MDK
> > becomes really 'just one' solution.
> > In fact, IMHO it is the Maven project itself that should be the home of
> > something like MDK.
> > Again, MDK is "just a tech demo".
> >
> >
> >> I understand what you mean but it is the case of the "current" solution.
> >> We don't need a new module nor anything outside plugins scope.
> >> The "do at end" on maven built-in components is even a pretty bad
> example
> >> cause it would be saner for the goal you describe to add a parameter on
> >> maven components methods more than a new concept IMHO - concretely
> enable
> >> this feature in repositorySystem directly which is already shared by
> >> design.
> >>
> >
> > This is the case where I'd like to _improve the current solution_ (as
> > opposed to "this is what it is, live with it") as I personally am not
> > satisfied with it.
> > Each provider has its own plugin and "recipe", that you must
> > adapt/incorporate (and pray it will not break with the following Maven
> > release), and so on and so on.
> > Hence the MDK demo and SPI pattern idea. Nothing new, as Maven Core
> always
> > worked like this, all I did was just documented it and created
> > a proof-of-concept (MDK).
> > Repository system has no notion of "at (maven) 

Re: [DISCUSS] MDK, a Maven Plugin SPI example

[Tamás Cservenák]

And few more things:
- my intent is to target BOTH, Maven3 and Maven4, as when Sonatype
deprecates OSS/S01 in favor of Central Portal, Maven3 (and currently also
Maven4) users are doomed to "roll their own" solutions for Central
publishing. While Sonatype Nx2 (running on Sonatype OSS/S01 and ASF repo)
can work to a certain degree with m-deploy-p (at the "cost" of logging in
to the UI, and pressing Close button on auto-created staging repository),
the new Central Portal will not work with it (as it seems from doco). IMHO,
we cannot leave Maven3 users behind, we cannot afford to leave Maven3 users
without any solution.
- MDK like solution could also provide support in cases like this (my next
task on radar):
https://lists.apache.org/thread/j3r4hvoonx6ftl8vlgs0fo4f2z9pmll5
- and finally, nothing forces you to use MDK, obviously. If you publish OCI
images or beam up little green people with Maven, you do not have to use
it! Solution is opt-in, that IS one of the key points of MDK :)

But to have ANY progress on ANY of this:
- the plugin SPIs needs to be created/released
- we need to use SPIs in plugins
- and only then we can provide seamless experience to our users


T


On Mon, May 6, 2024 at 8:24 PM Tamás Cservenák  wrote:

>
>> If you don't need to create a new module nor any new interface in maven
>> core or a shared module I'm all for the change, otherwise it is a new
>> shared thing whatever you present it.
>>
>
> So, if we don't change anything, you accept the "change"? :)
>
> In short: MDK is just a "tech demo", but the "real stuff" is:
> * introduce SPIs for targeted o.a.m.p plugins (the proposed ones are
> deploy and gpg plugins)
> * modify o.a.m.p plugins to use SPI pattern (again, m-deploy-p and m-gpg-p)
> * and from that moment on, we have an "open for all" game in play, as MDK
> becomes really 'just one' solution.
> In fact, IMHO it is the Maven project itself that should be the home of
> something like MDK.
> Again, MDK is "just a tech demo".
>
>
>> I understand what you mean but it is the case of the "current" solution.
>> We don't need a new module nor anything outside plugins scope.
>> The "do at end" on maven built-in components is even a pretty bad example
>> cause it would be saner for the goal you describe to add a parameter on
>> maven components methods more than a new concept IMHO - concretely enable
>> this feature in repositorySystem directly which is already shared by
>> design.
>>
>
> This is the case where I'd like to _improve the current solution_ (as
> opposed to "this is what it is, live with it") as I personally am not
> satisfied with it.
> Each provider has its own plugin and "recipe", that you must
> adapt/incorporate (and pray it will not break with the following Maven
> release), and so on and so on.
> Hence the MDK demo and SPI pattern idea. Nothing new, as Maven Core always
> worked like this, all I did was just documented it and created
> a proof-of-concept (MDK).
> Repository system has no notion of "at (maven) session end", but it does
> have "on session close" (which is happening way-way later).
> We discussed it and also rejected deploying at "on session end", we've
> been already there: https://github.com/apache/maven-resolver/pull/437
>
>
>>
>> As soon as you make a plugin "living" more than its execution you are no
>> more "dead simple" and have a ton of edge cases as the one you mentionned
>> which is a simple one where both cases can make sense (don't deploy if the
>> test fail or let it be deployed - depends if you release or dev, close to
>> "fail test at end").
>> If you take the deploy jar + oci container case, the recover case is not
>> trivial, the "deploy at end" is just a broken concept by design and
>> requires something different to recover.
>>
>> What I mean is that we cover way enough cases without adding a new thing
>> in
>> core and that moving just one step further is not sufficient in most cases
>> so the solution will be complex for a poor concrete gain so we should
>> probably look for something else - but I agree covering it completely is
>> quite more challenging cause either you can embrace reproducible builds
>> and
>> upsert/get-and-update or you have to burn a version (snapshot or not) if
>> you can't recover manually.
>>
>
> Again, IMHO you miss the point: m-deploy-p is not "living" more than
> execution (but, is NOT replaced either!). Quite the opposite!
> It works 'as before', and is really just like a "messenger". It does all
> and according to its config, and lives ONLY thru mojo execution.
> Unsure what you are aiming it with 'make a plugin "living" more than its
> execution' as none of that is happening here. Sigh.
>
> I heard for the first time that "deploy at end" is a broken concept. I
> have to strongly disagree here
> (and I am talking about Maven Artifact deployments, and I did talk
> about that ONLY, all the time. It is you who brought up OCI registry, not
> me)
>
>
>
>> No what you look at is "only artifacts deployment 

Re: [VOTE] Release Maven Site Plugin version 4.0.0-M14

[Karl Heinz Marbaise]

Hi,

+1 from me.

Kind regards
Karl Heinz Marbaise

PS.: Version Number related to Maven 4 API (was already mentioned).

On 05.05.24 21:29, Michael Osipov wrote:

Hi,

we solved 4 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317923=12354123

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSITE%20AND%20resolution%20%3D%20Unresolved

Staging repo:
https://repository.apache.org/content/repositories/maven-2109/
https://repository.apache.org/content/repositories/maven-2109/org/apache/maven/plugins/maven-site-plugin/4.0.0-M14/maven-site-plugin-4.0.0-M14-source-release.zip

Source release checksum(s):
maven-site-plugin-4.0.0-M14-source-release.zip
sha512:
cf9b896e1bc10b0bb81ded66f343e478da4da21300d10ac586ac08a8640bc7c11f25ff49d8f443c12e98011608c5d2db308d9b0b7ec1d9378d84616712b5b660

Staging site:
https://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

-
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

Re: [DISCUSS] MDK, a Maven Plugin SPI example

[Tamás Cservenák]

>
>
> If you don't need to create a new module nor any new interface in maven
> core or a shared module I'm all for the change, otherwise it is a new
> shared thing whatever you present it.
>

So, if we don't change anything, you accept the "change"? :)

In short: MDK is just a "tech demo", but the "real stuff" is:
* introduce SPIs for targeted o.a.m.p plugins (the proposed ones are deploy
and gpg plugins)
* modify o.a.m.p plugins to use SPI pattern (again, m-deploy-p and m-gpg-p)
* and from that moment on, we have an "open for all" game in play, as MDK
becomes really 'just one' solution.
In fact, IMHO it is the Maven project itself that should be the home of
something like MDK.
Again, MDK is "just a tech demo".


> I understand what you mean but it is the case of the "current" solution.
> We don't need a new module nor anything outside plugins scope.
> The "do at end" on maven built-in components is even a pretty bad example
> cause it would be saner for the goal you describe to add a parameter on
> maven components methods more than a new concept IMHO - concretely enable
> this feature in repositorySystem directly which is already shared by
> design.
>

This is the case where I'd like to _improve the current solution_ (as
opposed to "this is what it is, live with it") as I personally am not
satisfied with it.
Each provider has its own plugin and "recipe", that you must
adapt/incorporate (and pray it will not break with the following Maven
release), and so on and so on.
Hence the MDK demo and SPI pattern idea. Nothing new, as Maven Core always
worked like this, all I did was just documented it and created
a proof-of-concept (MDK).
Repository system has no notion of "at (maven) session end", but it does
have "on session close" (which is happening way-way later).
We discussed it and also rejected deploying at "on session end", we've been
already there: https://github.com/apache/maven-resolver/pull/437


>
> As soon as you make a plugin "living" more than its execution you are no
> more "dead simple" and have a ton of edge cases as the one you mentionned
> which is a simple one where both cases can make sense (don't deploy if the
> test fail or let it be deployed - depends if you release or dev, close to
> "fail test at end").
> If you take the deploy jar + oci container case, the recover case is not
> trivial, the "deploy at end" is just a broken concept by design and
> requires something different to recover.
>
> What I mean is that we cover way enough cases without adding a new thing in
> core and that moving just one step further is not sufficient in most cases
> so the solution will be complex for a poor concrete gain so we should
> probably look for something else - but I agree covering it completely is
> quite more challenging cause either you can embrace reproducible builds and
> upsert/get-and-update or you have to burn a version (snapshot or not) if
> you can't recover manually.
>

Again, IMHO you miss the point: m-deploy-p is not "living" more than
execution (but, is NOT replaced either!). Quite the opposite!
It works 'as before', and is really just like a "messenger". It does all
and according to its config, and lives ONLY thru mojo execution.
Unsure what you are aiming it with 'make a plugin "living" more than its
execution' as none of that is happening here. Sigh.

I heard for the first time that "deploy at end" is a broken concept. I have
to strongly disagree here
(and I am talking about Maven Artifact deployments, and I did talk
about that ONLY, all the time. It is you who brought up OCI registry, not
me)



> No what you look at is "only artifacts deployment done my way", but it
> breaks all the cases maven deploys something else - and once again it is
> not rare today.
>
>
Again, I _did_ talk all the time about "Maven artifact deployment"
(I thought it was clear, as if you look at SPI, you see Resolver classes.
You did look at sources, right?)
You can always bring up any example, like OCI containers, or little green
men or whatever,
but how does any of that come here?

T

Re: [DISCUSS] MDK, a Maven Plugin SPI example

[Romain Manni-Bucau]

Le lun. 6 mai 2024 à 19:40, Tamás Cservenák  a écrit :

> Howdy,
>
> inline.
>
>
> Exactly...this is what will always happen with plugins and extensions.
> > Indeed you can add a phase after plugins then you moved the issue to one
> > more step but the issue is still *exactly* the same but in a new concept
> > and layer, so literally no gain there.
> >
>
> This is not a new concept at all, one of the main reasons a lifecycle
> participant was added was exactly this,
> and the Takari lifecycle did leverage it for years. Unsure why this is a
> "new concept" for you.
>

If you don't need to create a new module nor any new interface in maven
core or a shared module I'm all for the change, otherwise it is a new
shared thing whatever you present it.


>
>
>
> > No issue there, you still control the reactor and therefore control the
> > last module built after all others if you want - I use that for the
> > documentation module of a 100+ modules project, so not an issue, you can
> > always have your last module have m-d-p.
> >
> >
> But that's the point! I don't want to author an Ant-like Maven build!
> I don't want to fiddle with each nit. I don't want to "fit carefully"
> sticks, tricks and hacks, build a house of cards or Jenga-build.
> I don't want to modify my build to "make it work". I don't want to adapt
> extra hoops and loops in my build "make it happen".
> I don't want "smart" and "intelligent" solutions. I don't want to check out
> a Maven project and spend time figuring out "how it works".
>
> I want simple wooden-wedge level solutions. I am in a "Dead Simple Maven
> Builds" camp.
>

I understand what you mean but it is the case of the "current" solution.
We don't need a new module nor anything outside plugins scope.
The "do at end" on maven built-in components is even a pretty bad example
cause it would be saner for the goal you describe to add a parameter on
maven components methods more than a new concept IMHO - concretely enable
this feature in repositorySystem directly which is already shared by design.

As soon as you make a plugin "living" more than its execution you are no
more "dead simple" and have a ton of edge cases as the one you mentionned
which is a simple one where both cases can make sense (don't deploy if the
test fail or let it be deployed - depends if you release or dev, close to
"fail test at end").
If you take the deploy jar + oci container case, the recover case is not
trivial, the "deploy at end" is just a broken concept by design and
requires something different to recover.

What I mean is that we cover way enough cases without adding a new thing in
core and that moving just one step further is not sufficient in most cases
so the solution will be complex for a poor concrete gain so we should
probably look for something else - but I agree covering it completely is
quite more challenging cause either you can embrace reproducible builds and
upsert/get-and-update or you have to burn a version (snapshot or not) if
you can't recover manually.


>
>
>
> > Not sure what you meant there but I don't see any mutilation:
> >
> > * you want to control more your lifecycle -> you can, indeed it requires
> > some configuration since it breaks the default setup but it is doable and
> > main case is still smooth (convention over config)
> > * you want to plug a custom impl in a plugin -> you can (Guillaume even
> did
> > the work for extensions)
> > * you want to make plugins working altogether sharing a coupled or
> loosely
> > coupled state? -> you can (using an extension to hold it or a generic
> > JVM/Maven type in the session data)
> >
> > So there is not yet any describe use case requiring a new concept in
> maven
> > AFAIK.
> >
>
> Explained above what I mean by "mutilation".
>
> But you can enumerate all the things you want, but still miss the point :)
> Again, this is not a "new tech" or anything, not a "revolutionary solution"
> for anything.
> This is IMHO "deployment done right" (and more to come).
>

No what you look at is "only artifacts deployment done my way", but it
breaks all the cases maven deploys something else - and once again it is
not rare today.


>
> Oh yes, and this thread is about MDK.
>

hehe, if so nothing to discuss ;)


>
> Thanks
> T
>

Re: [DISCUSS] MDK, a Maven Plugin SPI example

[Tamás Cservenák]

Howdy,

inline.


Exactly...this is what will always happen with plugins and extensions.
> Indeed you can add a phase after plugins then you moved the issue to one
> more step but the issue is still *exactly* the same but in a new concept
> and layer, so literally no gain there.
>

This is not a new concept at all, one of the main reasons a lifecycle
participant was added was exactly this,
and the Takari lifecycle did leverage it for years. Unsure why this is a
"new concept" for you.



> No issue there, you still control the reactor and therefore control the
> last module built after all others if you want - I use that for the
> documentation module of a 100+ modules project, so not an issue, you can
> always have your last module have m-d-p.
>
>
But that's the point! I don't want to author an Ant-like Maven build!
I don't want to fiddle with each nit. I don't want to "fit carefully"
sticks, tricks and hacks, build a house of cards or Jenga-build.
I don't want to modify my build to "make it work". I don't want to adapt
extra hoops and loops in my build "make it happen".
I don't want "smart" and "intelligent" solutions. I don't want to check out
a Maven project and spend time figuring out "how it works".

I want simple wooden-wedge level solutions. I am in a "Dead Simple Maven
Builds" camp.



> Not sure what you meant there but I don't see any mutilation:
>
> * you want to control more your lifecycle -> you can, indeed it requires
> some configuration since it breaks the default setup but it is doable and
> main case is still smooth (convention over config)
> * you want to plug a custom impl in a plugin -> you can (Guillaume even did
> the work for extensions)
> * you want to make plugins working altogether sharing a coupled or loosely
> coupled state? -> you can (using an extension to hold it or a generic
> JVM/Maven type in the session data)
>
> So there is not yet any describe use case requiring a new concept in maven
> AFAIK.
>

Explained above what I mean by "mutilation".

But you can enumerate all the things you want, but still miss the point :)
Again, this is not a "new tech" or anything, not a "revolutionary solution"
for anything.
This is IMHO "deployment done right" (and more to come).

Oh yes, and this thread is about MDK.

Thanks
T

Re: [DISCUSS] MDK, a Maven Plugin SPI example

[Romain Manni-Bucau]

Le lun. 6 mai 2024 à 18:55, Tamás Cservenák  a écrit :

> Romain,
>
> I have more and more the feeling that you are not reading what has been
> written down, at least not carefully enough.
>
> Otherwise, you';d know that is it NOT "already doable", as explained in MDK
> doco (but also in previous thread):
> Just one example: the current "deploy at end" feature of m-deploy-p does
> NOT deploy "at (build) end", but at "last module using m-deploy-p plugin".
> Hence, you can end up with deployment done, and afterwards a build failure.
>

Exactly...this is what will always happen with plugins and extensions.
Indeed you can add a phase after plugins then you moved the issue to one
more step but the issue is still *exactly* the same but in a new concept
and layer, so literally no gain there.


> For example some latter module running tests that use non-standard
> packaging and not using m-deploy-p on purpose.
>

No issue there, you still control the reactor and therefore control the
last module built after all others if you want - I use that for the
documentation module of a 100+ modules project, so not an issue, you can
always have your last module have m-d-p.


>
> Second, again as explained, the point is to NOT mutilate your build with
> hoops and loops, adapt to chosen build service,
> as if you choose (or you are forced) to move to another service, you would
> need to rinse-repeat, but this time for the other publishing service.
>

Not sure what you meant there but I don't see any mutilation:

* you want to control more your lifecycle -> you can, indeed it requires
some configuration since it breaks the default setup but it is doable and
main case is still smooth (convention over config)
* you want to plug a custom impl in a plugin -> you can (Guillaume even did
the work for extensions)
* you want to make plugins working altogether sharing a coupled or loosely
coupled state? -> you can (using an extension to hold it or a generic
JVM/Maven type in the session data)

So there is not yet any describe use case requiring a new concept in maven
AFAIK.


>
>
> Thanks
> T
>
>
>
> On Mon, May 6, 2024 at 5:56 PM Romain Manni-Bucau 
> wrote:
>
> > Hi Tamas
> >
> > So it is just a spi consommable from a plugin using an extension to
> share a
> > state accross mojo execution...so nothing we already do.
> >
> > My understanding of your request is to bring to maven 4 api this concept
> > for common needs (delayed tasks I'd say more than anything specific to
> > deployment).
> >
> > But presented as in the wiki value stays quite low  cause it is already
> > doable either with or without an extension - using the session and a
> plugin
> > running at the end of the build.
> >
> > Le lun. 6 mai 2024 à 18:37, Tamás Cservenák  a
> écrit
> > :
> >
> > > Howdy,
> > >
> > > Please take a peek at (and maybe try out) latest Maveniverse project,
> > MDK:
> > >
> > > https://github.com/maveniverse/mdk
> > >
> > > This is like "proof of concept" or "demo" of what the Plugin SPI
> pattern
> > > would be able to do.
> > >
> > > The idea is to broaden the support, and provide services even like
> > > "overlaid staging", when staging would receive deployments from
> multiple
> > > different sources (like for example OS native binaries).
> > >
> > > MDK is not yet, but will be integrated with Toolbox, to use it's sink
> > > abstraction:
> > > https://github.com/maveniverse/toolbox
> > >
> > > Have fun
> > > T
> > >
> >
>

Re: [DISCUSS] MDK, a Maven Plugin SPI example

[Tamás Cservenák]

Romain,

I have more and more the feeling that you are not reading what has been
written down, at least not carefully enough.

Otherwise, you';d know that is it NOT "already doable", as explained in MDK
doco (but also in previous thread):
Just one example: the current "deploy at end" feature of m-deploy-p does
NOT deploy "at (build) end", but at "last module using m-deploy-p plugin".
Hence, you can end up with deployment done, and afterwards a build failure.
For example some latter module running tests that use non-standard
packaging and not using m-deploy-p on purpose.

Second, again as explained, the point is to NOT mutilate your build with
hoops and loops, adapt to chosen build service,
as if you choose (or you are forced) to move to another service, you would
need to rinse-repeat, but this time for the other publishing service.


Thanks
T



On Mon, May 6, 2024 at 5:56 PM Romain Manni-Bucau 
wrote:

> Hi Tamas
>
> So it is just a spi consommable from a plugin using an extension to share a
> state accross mojo execution...so nothing we already do.
>
> My understanding of your request is to bring to maven 4 api this concept
> for common needs (delayed tasks I'd say more than anything specific to
> deployment).
>
> But presented as in the wiki value stays quite low  cause it is already
> doable either with or without an extension - using the session and a plugin
> running at the end of the build.
>
> Le lun. 6 mai 2024 à 18:37, Tamás Cservenák  a écrit
> :
>
> > Howdy,
> >
> > Please take a peek at (and maybe try out) latest Maveniverse project,
> MDK:
> >
> > https://github.com/maveniverse/mdk
> >
> > This is like "proof of concept" or "demo" of what the Plugin SPI pattern
> > would be able to do.
> >
> > The idea is to broaden the support, and provide services even like
> > "overlaid staging", when staging would receive deployments from multiple
> > different sources (like for example OS native binaries).
> >
> > MDK is not yet, but will be integrated with Toolbox, to use it's sink
> > abstraction:
> > https://github.com/maveniverse/toolbox
> >
> > Have fun
> > T
> >
>

Re: [DISCUSS] MDK, a Maven Plugin SPI example

[Romain Manni-Bucau]

Hi Tamas

So it is just a spi consommable from a plugin using an extension to share a
state accross mojo execution...so nothing we already do.

My understanding of your request is to bring to maven 4 api this concept
for common needs (delayed tasks I'd say more than anything specific to
deployment).

But presented as in the wiki value stays quite low  cause it is already
doable either with or without an extension - using the session and a plugin
running at the end of the build.

Le lun. 6 mai 2024 à 18:37, Tamás Cservenák  a écrit :

> Howdy,
>
> Please take a peek at (and maybe try out) latest Maveniverse project, MDK:
>
> https://github.com/maveniverse/mdk
>
> This is like "proof of concept" or "demo" of what the Plugin SPI pattern
> would be able to do.
>
> The idea is to broaden the support, and provide services even like
> "overlaid staging", when staging would receive deployments from multiple
> different sources (like for example OS native binaries).
>
> MDK is not yet, but will be integrated with Toolbox, to use it's sink
> abstraction:
> https://github.com/maveniverse/toolbox
>
> Have fun
> T
>

Re: [DISCUSS] Maven Plugin SPI

[Romain Manni-Bucau]

Hi Tamas

If the proposed options dont implement a SPI the  your solution neither
since there are equivalent, you are just more verbose and require more work
so still not following you.

Le lun. 6 mai 2024 à 18:45, Gary Gregory  a écrit :

> Please don't use the version in the GAV as marketing, this will be
> crazy-making for users IMO, especially if I have to look inside a jar to
> figure out what my expectations should be regarding semantic versioning.
>
> My view is that the user visible jar file name containing the version
> should set expectation for compatibility and how "risky" a plug-in update
> is, for example 2.3.4 to 2.3.5 should be 0-risk.
>
> Gary
>
> On Mon, May 6, 2024, 9:20 AM Guillaume Nodet  wrote:
>
> > I wonder if we should use proper package versioning (using
> > Specification-Title and Specification-Version manifest attributes, or any
> > other better mechanism)  and consider the artifact version as a marketing
> > version which should not carry any real semantics.
> >
> > Guillaume
> >
> > Le lun. 6 mai 2024 à 15:04, Tamás Cservenák  a
> écrit
> > :
> >
> > > Sure,
> > >
> > > Again, I am fine with having SPI artifact next to plugin consumer
> > artifact.
> > > All I wanted to prevent is having tens or more versions of SPI artifact
> > > released, while in fact they are "same thing".
> > >
> > > T
> > >
> > > On Mon, May 6, 2024 at 3:03 PM Guillaume Nodet 
> > wrote:
> > >
> > > > Le lun. 6 mai 2024 à 14:38, Tamás Cservenák  a
> > > écrit
> > > > :
> > > >
> > > > > lapsus: as in maven-core and maven-model SHOULD NOT share the same
> > > > release
> > > > > lifecycle. They DO currently.
> > > > > Which implies that we have as many maven-model artifacts released
> so
> > > far
> > > > as
> > > > > many maven, but many of them are binary equivalent to each other.
> > > > >
> > > >
> > > > What's the drawback with that ? It's much easier to handle for both
> the
> > > > developper side
> > > > and for the consumer side (they only have to upgrade a single version
> > > > instead of two).
> > > >
> > > > I'm quite on the opposite side, and I'd much rather simplify our
> > release
> > > > cycles rather
> > > > than going with one repo per jar...
> > > >
> > > >
> > > > > That's all I wanted to prevent. Am fine with having SPI next to the
> > > > plugin
> > > > > as well...
> > > > >
> > > > > T
> > > > >
> > > > > On Mon, May 6, 2024 at 2:36 PM Tamás Cservenák <
> ta...@cservenak.net>
> > > > > wrote:
> > > > >
> > > > > > Pretty much the same story as Maven models vs Maven "core"
> > > (maven-core
> > > > in
> > > > > > 3.x or api-imple in 4) they don't share the same release
> > > lifecycle.
> > > > > >
> > > > > > SPI is not to be changed often, while we do patch releases of the
> > > > > plugins.
> > > > > > Am not saying we cannot keep SPI along with Plugins, I am just
> > saying
> > > > > that
> > > > > > it's pointless: we will have many releases of the same thing.
> > > > > >
> > > > > > On Mon, May 6, 2024 at 2:31 PM Guillaume Nodet <
> gno...@apache.org>
> > > > > wrote:
> > > > > >
> > > > > >> Le lun. 6 mai 2024 à 14:29, Tamás Cservenák <
> ta...@cservenak.net>
> > a
> > > > > >> écrit :
> > > > > >>
> > > > > >> > Howdy,
> > > > > >> >
> > > > > >> > IIUC you have a problem with designated G?
> > > > > >> > As if so, that is really irrelevant. Point is that SPI cannot
> > > reside
> > > > > >> with
> > > > > >> > Plugin, as they share totally different release cycles.
> > > > > >> >
> > > > > >>
> > > > > >> Why ?
> > > > > >>
> > > > > >>
> > > > > >> >
> > > > > >> > Second, you mention a plugin dep, that is hence available in
> the
> > > > same
> > > > > >> scope
> > > > > >> > as the plugin itself...  which is obviously not enough in some
> > > > cases.
> > > > > >> >
> > > > > >> > T
> > > > > >> >
> > > > > >> > On Mon, May 6, 2024 at 2:25 PM Romain Manni-Bucau <
> > > > > >> rmannibu...@gmail.com>
> > > > > >> > wrote:
> > > > > >> >
> > > > > >> > > Hi Tamas,
> > > > > >> > >
> > > > > >> > > I kind of fail to see why org.apache.maven.maven-plugin-spi
> > > makes
> > > > > >> sense
> > > > > >> > > instead of org.apache.maven.plugins.$pluginArtifact-spi ?
> > > > > >> > > My understanding is that we already have that since any
> plugin
> > > can
> > > > > >> > define a
> > > > > >> > > specific SPI in its code and get it injected from a plugin
> dep
> > > > using
> > > > > >> its
> > > > > >> > >  block - exactly like shade plugin references
> > its
> > > > > >> > > transformers to be concrete.
> > > > > >> > > So for me nothing to create nor modify to get an old
> feature.
> > > > > >> > >
> > > > > >> > > Romain Manni-Bucau
> > > > > >> > > @rmannibucau  |  Blog
> > > > > >> > >  | Old Blog
> > > > > >> > >  | Github <
> > > > > >> > > https://github.com/rmannibucau> |
> > > > > >> > > LinkedIn  | Book
> > > > > >> > > <

Re: [DISCUSS] Maven Plugin SPI

[Gary Gregory]

Please don't use the version in the GAV as marketing, this will be
crazy-making for users IMO, especially if I have to look inside a jar to
figure out what my expectations should be regarding semantic versioning.

My view is that the user visible jar file name containing the version
should set expectation for compatibility and how "risky" a plug-in update
is, for example 2.3.4 to 2.3.5 should be 0-risk.

Gary

On Mon, May 6, 2024, 9:20 AM Guillaume Nodet  wrote:

> I wonder if we should use proper package versioning (using
> Specification-Title and Specification-Version manifest attributes, or any
> other better mechanism)  and consider the artifact version as a marketing
> version which should not carry any real semantics.
>
> Guillaume
>
> Le lun. 6 mai 2024 à 15:04, Tamás Cservenák  a écrit
> :
>
> > Sure,
> >
> > Again, I am fine with having SPI artifact next to plugin consumer
> artifact.
> > All I wanted to prevent is having tens or more versions of SPI artifact
> > released, while in fact they are "same thing".
> >
> > T
> >
> > On Mon, May 6, 2024 at 3:03 PM Guillaume Nodet 
> wrote:
> >
> > > Le lun. 6 mai 2024 à 14:38, Tamás Cservenák  a
> > écrit
> > > :
> > >
> > > > lapsus: as in maven-core and maven-model SHOULD NOT share the same
> > > release
> > > > lifecycle. They DO currently.
> > > > Which implies that we have as many maven-model artifacts released so
> > far
> > > as
> > > > many maven, but many of them are binary equivalent to each other.
> > > >
> > >
> > > What's the drawback with that ? It's much easier to handle for both the
> > > developper side
> > > and for the consumer side (they only have to upgrade a single version
> > > instead of two).
> > >
> > > I'm quite on the opposite side, and I'd much rather simplify our
> release
> > > cycles rather
> > > than going with one repo per jar...
> > >
> > >
> > > > That's all I wanted to prevent. Am fine with having SPI next to the
> > > plugin
> > > > as well...
> > > >
> > > > T
> > > >
> > > > On Mon, May 6, 2024 at 2:36 PM Tamás Cservenák 
> > > > wrote:
> > > >
> > > > > Pretty much the same story as Maven models vs Maven "core"
> > (maven-core
> > > in
> > > > > 3.x or api-imple in 4) they don't share the same release
> > lifecycle.
> > > > >
> > > > > SPI is not to be changed often, while we do patch releases of the
> > > > plugins.
> > > > > Am not saying we cannot keep SPI along with Plugins, I am just
> saying
> > > > that
> > > > > it's pointless: we will have many releases of the same thing.
> > > > >
> > > > > On Mon, May 6, 2024 at 2:31 PM Guillaume Nodet 
> > > > wrote:
> > > > >
> > > > >> Le lun. 6 mai 2024 à 14:29, Tamás Cservenák 
> a
> > > > >> écrit :
> > > > >>
> > > > >> > Howdy,
> > > > >> >
> > > > >> > IIUC you have a problem with designated G?
> > > > >> > As if so, that is really irrelevant. Point is that SPI cannot
> > reside
> > > > >> with
> > > > >> > Plugin, as they share totally different release cycles.
> > > > >> >
> > > > >>
> > > > >> Why ?
> > > > >>
> > > > >>
> > > > >> >
> > > > >> > Second, you mention a plugin dep, that is hence available in the
> > > same
> > > > >> scope
> > > > >> > as the plugin itself...  which is obviously not enough in some
> > > cases.
> > > > >> >
> > > > >> > T
> > > > >> >
> > > > >> > On Mon, May 6, 2024 at 2:25 PM Romain Manni-Bucau <
> > > > >> rmannibu...@gmail.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > Hi Tamas,
> > > > >> > >
> > > > >> > > I kind of fail to see why org.apache.maven.maven-plugin-spi
> > makes
> > > > >> sense
> > > > >> > > instead of org.apache.maven.plugins.$pluginArtifact-spi ?
> > > > >> > > My understanding is that we already have that since any plugin
> > can
> > > > >> > define a
> > > > >> > > specific SPI in its code and get it injected from a plugin dep
> > > using
> > > > >> its
> > > > >> > >  block - exactly like shade plugin references
> its
> > > > >> > > transformers to be concrete.
> > > > >> > > So for me nothing to create nor modify to get an old feature.
> > > > >> > >
> > > > >> > > Romain Manni-Bucau
> > > > >> > > @rmannibucau  |  Blog
> > > > >> > >  | Old Blog
> > > > >> > >  | Github <
> > > > >> > > https://github.com/rmannibucau> |
> > > > >> > > LinkedIn  | Book
> > > > >> > > <
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >> > > >
> > > > >> > >
> > > > >> > >
> > > > >> > > Le lun. 6 mai 2024 à 14:08, Tamás Cservenák <
> > ta...@cservenak.net>
> > > a
> > > > >> > écrit
> > > > >> > > :
> > > > >> > >
> > > > >> > > > Howdy,
> > > > >> > > >
> > > > >> > > > I'd like to create a new ASF Maven git repo
> > "maven-plugin-spi".
> > > > >> > > >
> > > > >> > > > This repository would hold SPIs as explained here
> > > > >> > > >
> > > > 

[DISCUSS] MDK, a Maven Plugin SPI example

[Tamás Cservenák]

Howdy,

Please take a peek at (and maybe try out) latest Maveniverse project, MDK:

https://github.com/maveniverse/mdk

This is like "proof of concept" or "demo" of what the Plugin SPI pattern
would be able to do.

The idea is to broaden the support, and provide services even like
"overlaid staging", when staging would receive deployments from multiple
different sources (like for example OS native binaries).

MDK is not yet, but will be integrated with Toolbox, to use it's sink
abstraction:
https://github.com/maveniverse/toolbox

Have fun
T

Re: [DISCUSS] Maven Plugin SPI

[Tamás Cservenák]

This is IMHO not "great and powerful" but "dangerous and sneaky" option...

For starters, assume the user build fails with an error "failure in mojo
Foo", opens his POM, and will have no idea what mojo Foo is, as it is _not
even there_ (magic!)...

Second, you can _replace_ but not _extend_ existing plugin with this hack.
For example if you want to add 3rd feature (to existing 2 features of some
plugin), then your "replacement" plugin that is injected instead of the
original, would need to _reimplement_ (copy pasta?) the 2 features. I find
this redundant and plain wrong.

Third, I don't think that any of these solutions you mention implement the
SPI pattern, that this thread IS about.

T




On Mon, May 6, 2024 at 4:07 PM Romain Manni-Bucau 
wrote:

> Le lun. 6 mai 2024 à 16:00, Tamás Cservenák  a écrit
> :
>
> > Romain,
> >
> > for start, you are referring to a solution to "mangle the model after it
> > was read up". This is what nexus-staging-m-p does and I consider it wrong
> > and possibly illegal (despite the fact that I wrote that plugin).
> >
>
> I disagree, this was our choice and this is a great and powerful option.
> Moreover I think it is way more wrong to redo a solution which is already
> done cause of the mess in the code but also the comm it creates.
>
>
> > This is not a future proof way to do it. To be precise, nx-staging-m-p
> > injects m-deploy-p config (to become skipped), and also injects itself
> > (deploy) goal to become "Caliph instead of Caliph" (to deploy instead of
> > m-deploy-p) (ref  https://en.wikipedia.org/wiki/Iznogoud)
> >
>
> Rightwhich is great.
> We do the same in junit-platform plugin for goods.
>
>
> >
> > Other than that, I see no way how you could "alter" m-deploy-p behaviour
> > using this technique, as:
> > - here you can rewrite the POM
> > - rewrite plugin config
> > - but you cannot add/replace components from the plugin itself
> > - you CAN do what nx-staging does (remote/disable it, and inject
> yourself,
> > but again, I find this bad practice)
> >
> > Last bullet is a hack, I hope we both agree on this.
> >
>
> Right but you spoke about creating spi so explicitly enabling the N-1 point
> (injecting a component in configuration)so we are covered for all cases
> already.
> If you want an auto-discovered case you don't cover the case you describe,
> ie enable/disable deployAtEnd so I still don't see any issue for now.
>
>
> >
> > T
> >
> > T
> >
> > On Mon, May 6, 2024 at 3:52 PM Romain Manni-Bucau  >
> > wrote:
> >
> > >
> > >
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/AbstractMavenLifecycleParticipant.java#L44
> > > afterProjectsRead sorry
> > >
> > > So long story short you have a clean way to handle SPI from plugins
> with
> > > explicit configuration from the pom or transversally from an extension.
> > > I don't see a case in between since user is not able to consume it.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le lun. 6 mai 2024 à 15:48, Tamás Cservenák  a
> > écrit
> > > :
> > >
> > > > Romain,
> > > >
> > > > could you elaborate what you mean by this:
> > > > "At startup it does not need to be there, so there is no issue there
> > > while
> > > > you resolve the plugin dependency you inject from the extension in
> > > > afterModelRead normally."
> > > >
> > > > What is "afterModelRead"?
> > > >
> > > > T
> > > >
> > > >
> > > > On Mon, May 6, 2024 at 3:40 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Tamas, the extension can inject the configuration which is
> > instantiated
> > > > > when the mojo will be executed.
> > > > > At startup it does not need to be there, so there is no issue there
> > > while
> > > > > you resolve the plugin dependency you inject from the extension in
> > > > > afterModelRead normally.
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau  |  Blog
> > > > >  | Old Blog
> > > > >  | Github <
> > > > > https://github.com/rmannibucau> |
> > > > > LinkedIn  | Book
> > > > > <
> > > > >
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > >
> > > > >
> > > > >
> > > > > Le lun. 6 mai 2024 à 15:36, Tamás Cservenák 
> a
> > > > écrit
> > > > > :
> > > > >
> > > > > > Laeubi,
> > > > > >
> > > > > > How does tycho use plugin-spi? Can you show me some Tycho
> > plugin-spi
> > > > > > examples?
> > > > > >
> > > > > > As in case of Maven (proper, so 

Re: [DISCUSS] Maven Plugin SPI

[Romain Manni-Bucau]

Le lun. 6 mai 2024 à 16:00, Tamás Cservenák  a écrit :

> Romain,
>
> for start, you are referring to a solution to "mangle the model after it
> was read up". This is what nexus-staging-m-p does and I consider it wrong
> and possibly illegal (despite the fact that I wrote that plugin).
>

I disagree, this was our choice and this is a great and powerful option.
Moreover I think it is way more wrong to redo a solution which is already
done cause of the mess in the code but also the comm it creates.


> This is not a future proof way to do it. To be precise, nx-staging-m-p
> injects m-deploy-p config (to become skipped), and also injects itself
> (deploy) goal to become "Caliph instead of Caliph" (to deploy instead of
> m-deploy-p) (ref  https://en.wikipedia.org/wiki/Iznogoud)
>

Rightwhich is great.
We do the same in junit-platform plugin for goods.


>
> Other than that, I see no way how you could "alter" m-deploy-p behaviour
> using this technique, as:
> - here you can rewrite the POM
> - rewrite plugin config
> - but you cannot add/replace components from the plugin itself
> - you CAN do what nx-staging does (remote/disable it, and inject yourself,
> but again, I find this bad practice)
>
> Last bullet is a hack, I hope we both agree on this.
>

Right but you spoke about creating spi so explicitly enabling the N-1 point
(injecting a component in configuration)so we are covered for all cases
already.
If you want an auto-discovered case you don't cover the case you describe,
ie enable/disable deployAtEnd so I still don't see any issue for now.


>
> T
>
> T
>
> On Mon, May 6, 2024 at 3:52 PM Romain Manni-Bucau 
> wrote:
>
> >
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/AbstractMavenLifecycleParticipant.java#L44
> > afterProjectsRead sorry
> >
> > So long story short you have a clean way to handle SPI from plugins with
> > explicit configuration from the pom or transversally from an extension.
> > I don't see a case in between since user is not able to consume it.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le lun. 6 mai 2024 à 15:48, Tamás Cservenák  a
> écrit
> > :
> >
> > > Romain,
> > >
> > > could you elaborate what you mean by this:
> > > "At startup it does not need to be there, so there is no issue there
> > while
> > > you resolve the plugin dependency you inject from the extension in
> > > afterModelRead normally."
> > >
> > > What is "afterModelRead"?
> > >
> > > T
> > >
> > >
> > > On Mon, May 6, 2024 at 3:40 PM Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > > wrote:
> > >
> > > > Tamas, the extension can inject the configuration which is
> instantiated
> > > > when the mojo will be executed.
> > > > At startup it does not need to be there, so there is no issue there
> > while
> > > > you resolve the plugin dependency you inject from the extension in
> > > > afterModelRead normally.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn  | Book
> > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > Le lun. 6 mai 2024 à 15:36, Tamás Cservenák  a
> > > écrit
> > > > :
> > > >
> > > > > Laeubi,
> > > > >
> > > > > How does tycho use plugin-spi? Can you show me some Tycho
> plugin-spi
> > > > > examples?
> > > > >
> > > > > As in case of Maven (proper, so "vanilla"), core extension is
> loaded
> > > > first
> > > > > (early), that would like to define SPI implementations, but the
> > plugin
> > > > that
> > > > > would carry SPI interfaces, if SPI would be within plugin as
> > proposed,
> > > is
> > > > > "yet to be seen", will be loaded by mvn core on first encounter in
> > > > > lifecycle. Or, if both load SPI interfaces, they will end up in two
> > > > > classloaders, again defunct.
> > > > >
> > > > > And yes, this solution would enable -- depending on SPI -- to
> extend
> > > > > existing SPI enabled-plugin in various ways, without touching the
> > > > > build/POMs itself.
> > > > >
> > > > >
> > > > > T
> > > > >
> > > > >
> > > > > On Mon, May 6, 2024 at 2:46 PM Christoph Läubrich <
> > m...@laeubi-soft.de
> > > >
> > > > > wrote:
> > > > >
> > > > > > Hi Tamas,
> > > > > >
> > > > > > I'm specifically asking because Tycho has already a plugin-spi
> > > support
> > > > > > we use to a great extent, so if there would be a general usable
> > > > solution
> > 

Re: [DISCUSS] Maven Plugin SPI

[Tamás Cservenák]

Romain,

for start, you are referring to a solution to "mangle the model after it
was read up". This is what nexus-staging-m-p does and I consider it wrong
and possibly illegal (despite the fact that I wrote that plugin).
This is not a future proof way to do it. To be precise, nx-staging-m-p
injects m-deploy-p config (to become skipped), and also injects itself
(deploy) goal to become "Caliph instead of Caliph" (to deploy instead of
m-deploy-p) (ref  https://en.wikipedia.org/wiki/Iznogoud)

Other than that, I see no way how you could "alter" m-deploy-p behaviour
using this technique, as:
- here you can rewrite the POM
- rewrite plugin config
- but you cannot add/replace components from the plugin itself
- you CAN do what nx-staging does (remote/disable it, and inject yourself,
but again, I find this bad practice)

Last bullet is a hack, I hope we both agree on this.

T

T

On Mon, May 6, 2024 at 3:52 PM Romain Manni-Bucau 
wrote:

>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/AbstractMavenLifecycleParticipant.java#L44
> afterProjectsRead sorry
>
> So long story short you have a clean way to handle SPI from plugins with
> explicit configuration from the pom or transversally from an extension.
> I don't see a case in between since user is not able to consume it.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 6 mai 2024 à 15:48, Tamás Cservenák  a écrit
> :
>
> > Romain,
> >
> > could you elaborate what you mean by this:
> > "At startup it does not need to be there, so there is no issue there
> while
> > you resolve the plugin dependency you inject from the extension in
> > afterModelRead normally."
> >
> > What is "afterModelRead"?
> >
> > T
> >
> >
> > On Mon, May 6, 2024 at 3:40 PM Romain Manni-Bucau  >
> > wrote:
> >
> > > Tamas, the extension can inject the configuration which is instantiated
> > > when the mojo will be executed.
> > > At startup it does not need to be there, so there is no issue there
> while
> > > you resolve the plugin dependency you inject from the extension in
> > > afterModelRead normally.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le lun. 6 mai 2024 à 15:36, Tamás Cservenák  a
> > écrit
> > > :
> > >
> > > > Laeubi,
> > > >
> > > > How does tycho use plugin-spi? Can you show me some Tycho plugin-spi
> > > > examples?
> > > >
> > > > As in case of Maven (proper, so "vanilla"), core extension is loaded
> > > first
> > > > (early), that would like to define SPI implementations, but the
> plugin
> > > that
> > > > would carry SPI interfaces, if SPI would be within plugin as
> proposed,
> > is
> > > > "yet to be seen", will be loaded by mvn core on first encounter in
> > > > lifecycle. Or, if both load SPI interfaces, they will end up in two
> > > > classloaders, again defunct.
> > > >
> > > > And yes, this solution would enable -- depending on SPI -- to extend
> > > > existing SPI enabled-plugin in various ways, without touching the
> > > > build/POMs itself.
> > > >
> > > >
> > > > T
> > > >
> > > >
> > > > On Mon, May 6, 2024 at 2:46 PM Christoph Läubrich <
> m...@laeubi-soft.de
> > >
> > > > wrote:
> > > >
> > > > > Hi Tamas,
> > > > >
> > > > > I'm specifically asking because Tycho has already a plugin-spi
> > support
> > > > > we use to a great extent, so if there would be a general usable
> > > solution
> > > > > that would be great I even asked many times for it but always got
> > "use
> > > > > an extension" so I wonder what changed the mind of maven-devs or if
> > it
> > > > > will be just another thing exclusive to "maven-core-plugins" or can
> > > > > other reuse that (how?). And if others can reuse it, why have a
> > > > > dedicated repository and not use the repository of the plugin that
> > > > > offers the spi?
> > > > >
> > > > > Am 06.05.24 um 14:08 schrieb Tamás Cservenák:
> > > > > > Howdy,
> > > > > >
> > > > > > I'd like to create a new ASF Maven git repo "maven-plugin-spi".
> > > > > >
> > > > > > This repository would hold SPIs as explained here
> > > > > >
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI
> > > > > >
> > > > > > Designated G: "org.apache.maven.maven-plugin-spi"
> > > > > >
> > > > > > For now, we have two candidates to apply SPI pattern:
> > > > > > * maven-deploy-plugin (yet to be added)

Re: [DISCUSS] Maven Plugin SPI

[Romain Manni-Bucau]

https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/AbstractMavenLifecycleParticipant.java#L44
afterProjectsRead sorry

So long story short you have a clean way to handle SPI from plugins with
explicit configuration from the pom or transversally from an extension.
I don't see a case in between since user is not able to consume it.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 6 mai 2024 à 15:48, Tamás Cservenák  a écrit :

> Romain,
>
> could you elaborate what you mean by this:
> "At startup it does not need to be there, so there is no issue there while
> you resolve the plugin dependency you inject from the extension in
> afterModelRead normally."
>
> What is "afterModelRead"?
>
> T
>
>
> On Mon, May 6, 2024 at 3:40 PM Romain Manni-Bucau 
> wrote:
>
> > Tamas, the extension can inject the configuration which is instantiated
> > when the mojo will be executed.
> > At startup it does not need to be there, so there is no issue there while
> > you resolve the plugin dependency you inject from the extension in
> > afterModelRead normally.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le lun. 6 mai 2024 à 15:36, Tamás Cservenák  a
> écrit
> > :
> >
> > > Laeubi,
> > >
> > > How does tycho use plugin-spi? Can you show me some Tycho plugin-spi
> > > examples?
> > >
> > > As in case of Maven (proper, so "vanilla"), core extension is loaded
> > first
> > > (early), that would like to define SPI implementations, but the plugin
> > that
> > > would carry SPI interfaces, if SPI would be within plugin as proposed,
> is
> > > "yet to be seen", will be loaded by mvn core on first encounter in
> > > lifecycle. Or, if both load SPI interfaces, they will end up in two
> > > classloaders, again defunct.
> > >
> > > And yes, this solution would enable -- depending on SPI -- to extend
> > > existing SPI enabled-plugin in various ways, without touching the
> > > build/POMs itself.
> > >
> > >
> > > T
> > >
> > >
> > > On Mon, May 6, 2024 at 2:46 PM Christoph Läubrich  >
> > > wrote:
> > >
> > > > Hi Tamas,
> > > >
> > > > I'm specifically asking because Tycho has already a plugin-spi
> support
> > > > we use to a great extent, so if there would be a general usable
> > solution
> > > > that would be great I even asked many times for it but always got
> "use
> > > > an extension" so I wonder what changed the mind of maven-devs or if
> it
> > > > will be just another thing exclusive to "maven-core-plugins" or can
> > > > other reuse that (how?). And if others can reuse it, why have a
> > > > dedicated repository and not use the repository of the plugin that
> > > > offers the spi?
> > > >
> > > > Am 06.05.24 um 14:08 schrieb Tamás Cservenák:
> > > > > Howdy,
> > > > >
> > > > > I'd like to create a new ASF Maven git repo "maven-plugin-spi".
> > > > >
> > > > > This repository would hold SPIs as explained here
> > > > > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI
> > > > >
> > > > > Designated G: "org.apache.maven.maven-plugin-spi"
> > > > >
> > > > > For now, we have two candidates to apply SPI pattern:
> > > > > * maven-deploy-plugin (yet to be added)
> > > > > * maven-gpg-plugin (already have it, but in unusable form, as it
> does
> > > not
> > > > > follow pattern from wiki)
> > > > >
> > > > > Example GAs:
> > > > > org.apache.maven.maven-plugin-spi:maven-deploy-spi
> > > > > org.apache.maven.maven-plugin-spi:maven-gpg-spi
> > > > >
> > > > > Thanks
> > > > > T
> > > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Maven Plugin SPI

[Tamás Cservenák]

Romain,

could you elaborate what you mean by this:
"At startup it does not need to be there, so there is no issue there while
you resolve the plugin dependency you inject from the extension in
afterModelRead normally."

What is "afterModelRead"?

T


On Mon, May 6, 2024 at 3:40 PM Romain Manni-Bucau 
wrote:

> Tamas, the extension can inject the configuration which is instantiated
> when the mojo will be executed.
> At startup it does not need to be there, so there is no issue there while
> you resolve the plugin dependency you inject from the extension in
> afterModelRead normally.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 6 mai 2024 à 15:36, Tamás Cservenák  a écrit
> :
>
> > Laeubi,
> >
> > How does tycho use plugin-spi? Can you show me some Tycho plugin-spi
> > examples?
> >
> > As in case of Maven (proper, so "vanilla"), core extension is loaded
> first
> > (early), that would like to define SPI implementations, but the plugin
> that
> > would carry SPI interfaces, if SPI would be within plugin as proposed, is
> > "yet to be seen", will be loaded by mvn core on first encounter in
> > lifecycle. Or, if both load SPI interfaces, they will end up in two
> > classloaders, again defunct.
> >
> > And yes, this solution would enable -- depending on SPI -- to extend
> > existing SPI enabled-plugin in various ways, without touching the
> > build/POMs itself.
> >
> >
> > T
> >
> >
> > On Mon, May 6, 2024 at 2:46 PM Christoph Läubrich 
> > wrote:
> >
> > > Hi Tamas,
> > >
> > > I'm specifically asking because Tycho has already a plugin-spi support
> > > we use to a great extent, so if there would be a general usable
> solution
> > > that would be great I even asked many times for it but always got "use
> > > an extension" so I wonder what changed the mind of maven-devs or if it
> > > will be just another thing exclusive to "maven-core-plugins" or can
> > > other reuse that (how?). And if others can reuse it, why have a
> > > dedicated repository and not use the repository of the plugin that
> > > offers the spi?
> > >
> > > Am 06.05.24 um 14:08 schrieb Tamás Cservenák:
> > > > Howdy,
> > > >
> > > > I'd like to create a new ASF Maven git repo "maven-plugin-spi".
> > > >
> > > > This repository would hold SPIs as explained here
> > > > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI
> > > >
> > > > Designated G: "org.apache.maven.maven-plugin-spi"
> > > >
> > > > For now, we have two candidates to apply SPI pattern:
> > > > * maven-deploy-plugin (yet to be added)
> > > > * maven-gpg-plugin (already have it, but in unusable form, as it does
> > not
> > > > follow pattern from wiki)
> > > >
> > > > Example GAs:
> > > > org.apache.maven.maven-plugin-spi:maven-deploy-spi
> > > > org.apache.maven.maven-plugin-spi:maven-gpg-spi
> > > >
> > > > Thanks
> > > > T
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>

Re: [DISCUSS] Maven Plugin SPI

[Romain Manni-Bucau]

Tamas, the extension can inject the configuration which is instantiated
when the mojo will be executed.
At startup it does not need to be there, so there is no issue there while
you resolve the plugin dependency you inject from the extension in
afterModelRead normally.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 6 mai 2024 à 15:36, Tamás Cservenák  a écrit :

> Laeubi,
>
> How does tycho use plugin-spi? Can you show me some Tycho plugin-spi
> examples?
>
> As in case of Maven (proper, so "vanilla"), core extension is loaded first
> (early), that would like to define SPI implementations, but the plugin that
> would carry SPI interfaces, if SPI would be within plugin as proposed, is
> "yet to be seen", will be loaded by mvn core on first encounter in
> lifecycle. Or, if both load SPI interfaces, they will end up in two
> classloaders, again defunct.
>
> And yes, this solution would enable -- depending on SPI -- to extend
> existing SPI enabled-plugin in various ways, without touching the
> build/POMs itself.
>
>
> T
>
>
> On Mon, May 6, 2024 at 2:46 PM Christoph Läubrich 
> wrote:
>
> > Hi Tamas,
> >
> > I'm specifically asking because Tycho has already a plugin-spi support
> > we use to a great extent, so if there would be a general usable solution
> > that would be great I even asked many times for it but always got "use
> > an extension" so I wonder what changed the mind of maven-devs or if it
> > will be just another thing exclusive to "maven-core-plugins" or can
> > other reuse that (how?). And if others can reuse it, why have a
> > dedicated repository and not use the repository of the plugin that
> > offers the spi?
> >
> > Am 06.05.24 um 14:08 schrieb Tamás Cservenák:
> > > Howdy,
> > >
> > > I'd like to create a new ASF Maven git repo "maven-plugin-spi".
> > >
> > > This repository would hold SPIs as explained here
> > > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI
> > >
> > > Designated G: "org.apache.maven.maven-plugin-spi"
> > >
> > > For now, we have two candidates to apply SPI pattern:
> > > * maven-deploy-plugin (yet to be added)
> > > * maven-gpg-plugin (already have it, but in unusable form, as it does
> not
> > > follow pattern from wiki)
> > >
> > > Example GAs:
> > > org.apache.maven.maven-plugin-spi:maven-deploy-spi
> > > org.apache.maven.maven-plugin-spi:maven-gpg-spi
> > >
> > > Thanks
> > > T
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [DISCUSS] Maven Plugin SPI

[Tamás Cservenák]

Laeubi,

How does tycho use plugin-spi? Can you show me some Tycho plugin-spi
examples?

As in case of Maven (proper, so "vanilla"), core extension is loaded first
(early), that would like to define SPI implementations, but the plugin that
would carry SPI interfaces, if SPI would be within plugin as proposed, is
"yet to be seen", will be loaded by mvn core on first encounter in
lifecycle. Or, if both load SPI interfaces, they will end up in two
classloaders, again defunct.

And yes, this solution would enable -- depending on SPI -- to extend
existing SPI enabled-plugin in various ways, without touching the
build/POMs itself.


T


On Mon, May 6, 2024 at 2:46 PM Christoph Läubrich 
wrote:

> Hi Tamas,
>
> I'm specifically asking because Tycho has already a plugin-spi support
> we use to a great extent, so if there would be a general usable solution
> that would be great I even asked many times for it but always got "use
> an extension" so I wonder what changed the mind of maven-devs or if it
> will be just another thing exclusive to "maven-core-plugins" or can
> other reuse that (how?). And if others can reuse it, why have a
> dedicated repository and not use the repository of the plugin that
> offers the spi?
>
> Am 06.05.24 um 14:08 schrieb Tamás Cservenák:
> > Howdy,
> >
> > I'd like to create a new ASF Maven git repo "maven-plugin-spi".
> >
> > This repository would hold SPIs as explained here
> > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI
> >
> > Designated G: "org.apache.maven.maven-plugin-spi"
> >
> > For now, we have two candidates to apply SPI pattern:
> > * maven-deploy-plugin (yet to be added)
> > * maven-gpg-plugin (already have it, but in unusable form, as it does not
> > follow pattern from wiki)
> >
> > Example GAs:
> > org.apache.maven.maven-plugin-spi:maven-deploy-spi
> > org.apache.maven.maven-plugin-spi:maven-gpg-spi
> >
> > Thanks
> > T
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] Maven Plugin SPI

[Romain Manni-Bucau]

Think there is something miscommunicated there.

here is my vision:

1. "user" maven spi ->
https://github.com/apache/maven/tree/master/api/maven-api-spi
2. plugin spi -> belongs by design to plugin (= the plugin chooses its SPI)
so belongs to plugin project to keep thing simples - having one repo by
plugin is good but already challenging so x2 the number of repo for spi is
likely the promise of a mess and a ton of pointless compatibility matrixes.
Side note here being we solved it and it works well for dev and consumers.
3. shared plugin spi -> put it in shared module (but even if the lifecycle
can look shared the details of the plugin will not IMHO so think we'll
always be in 2 or we'll move all plugins SPI in a shared module which is
worse IMHO)
4. anything else stays in extension and it would be bad for us - makes it
complex for us but also mojo writers and end users - to redo an extension
concurrent for other needs than the previous one

So ultimately I think this is not an issue we need to address even if any
use case can get multiple solutions, a single one is often the best
compromise for everyone.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 6 mai 2024 à 15:20, Guillaume Nodet  a écrit :

> I wonder if we should use proper package versioning (using
> Specification-Title and Specification-Version manifest attributes, or any
> other better mechanism)  and consider the artifact version as a marketing
> version which should not carry any real semantics.
>
> Guillaume
>
> Le lun. 6 mai 2024 à 15:04, Tamás Cservenák  a écrit
> :
>
> > Sure,
> >
> > Again, I am fine with having SPI artifact next to plugin consumer
> artifact.
> > All I wanted to prevent is having tens or more versions of SPI artifact
> > released, while in fact they are "same thing".
> >
> > T
> >
> > On Mon, May 6, 2024 at 3:03 PM Guillaume Nodet 
> wrote:
> >
> > > Le lun. 6 mai 2024 à 14:38, Tamás Cservenák  a
> > écrit
> > > :
> > >
> > > > lapsus: as in maven-core and maven-model SHOULD NOT share the same
> > > release
> > > > lifecycle. They DO currently.
> > > > Which implies that we have as many maven-model artifacts released so
> > far
> > > as
> > > > many maven, but many of them are binary equivalent to each other.
> > > >
> > >
> > > What's the drawback with that ? It's much easier to handle for both the
> > > developper side
> > > and for the consumer side (they only have to upgrade a single version
> > > instead of two).
> > >
> > > I'm quite on the opposite side, and I'd much rather simplify our
> release
> > > cycles rather
> > > than going with one repo per jar...
> > >
> > >
> > > > That's all I wanted to prevent. Am fine with having SPI next to the
> > > plugin
> > > > as well...
> > > >
> > > > T
> > > >
> > > > On Mon, May 6, 2024 at 2:36 PM Tamás Cservenák 
> > > > wrote:
> > > >
> > > > > Pretty much the same story as Maven models vs Maven "core"
> > (maven-core
> > > in
> > > > > 3.x or api-imple in 4) they don't share the same release
> > lifecycle.
> > > > >
> > > > > SPI is not to be changed often, while we do patch releases of the
> > > > plugins.
> > > > > Am not saying we cannot keep SPI along with Plugins, I am just
> saying
> > > > that
> > > > > it's pointless: we will have many releases of the same thing.
> > > > >
> > > > > On Mon, May 6, 2024 at 2:31 PM Guillaume Nodet 
> > > > wrote:
> > > > >
> > > > >> Le lun. 6 mai 2024 à 14:29, Tamás Cservenák 
> a
> > > > >> écrit :
> > > > >>
> > > > >> > Howdy,
> > > > >> >
> > > > >> > IIUC you have a problem with designated G?
> > > > >> > As if so, that is really irrelevant. Point is that SPI cannot
> > reside
> > > > >> with
> > > > >> > Plugin, as they share totally different release cycles.
> > > > >> >
> > > > >>
> > > > >> Why ?
> > > > >>
> > > > >>
> > > > >> >
> > > > >> > Second, you mention a plugin dep, that is hence available in the
> > > same
> > > > >> scope
> > > > >> > as the plugin itself...  which is obviously not enough in some
> > > cases.
> > > > >> >
> > > > >> > T
> > > > >> >
> > > > >> > On Mon, May 6, 2024 at 2:25 PM Romain Manni-Bucau <
> > > > >> rmannibu...@gmail.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > Hi Tamas,
> > > > >> > >
> > > > >> > > I kind of fail to see why org.apache.maven.maven-plugin-spi
> > makes
> > > > >> sense
> > > > >> > > instead of org.apache.maven.plugins.$pluginArtifact-spi ?
> > > > >> > > My understanding is that we already have that since any plugin
> > can
> > > > >> > define a
> > > > >> > > specific SPI in its code and get it injected from a plugin dep
> > > using
> > > > >> its
> > > > >> > >  block - exactly like shade plugin references
> its
> > > > >> > > transformers to be concrete.

Re: [DISCUSS] Maven Plugin SPI

[Guillaume Nodet]

I wonder if we should use proper package versioning (using
Specification-Title and Specification-Version manifest attributes, or any
other better mechanism)  and consider the artifact version as a marketing
version which should not carry any real semantics.

Guillaume

Le lun. 6 mai 2024 à 15:04, Tamás Cservenák  a écrit :

> Sure,
>
> Again, I am fine with having SPI artifact next to plugin consumer artifact.
> All I wanted to prevent is having tens or more versions of SPI artifact
> released, while in fact they are "same thing".
>
> T
>
> On Mon, May 6, 2024 at 3:03 PM Guillaume Nodet  wrote:
>
> > Le lun. 6 mai 2024 à 14:38, Tamás Cservenák  a
> écrit
> > :
> >
> > > lapsus: as in maven-core and maven-model SHOULD NOT share the same
> > release
> > > lifecycle. They DO currently.
> > > Which implies that we have as many maven-model artifacts released so
> far
> > as
> > > many maven, but many of them are binary equivalent to each other.
> > >
> >
> > What's the drawback with that ? It's much easier to handle for both the
> > developper side
> > and for the consumer side (they only have to upgrade a single version
> > instead of two).
> >
> > I'm quite on the opposite side, and I'd much rather simplify our release
> > cycles rather
> > than going with one repo per jar...
> >
> >
> > > That's all I wanted to prevent. Am fine with having SPI next to the
> > plugin
> > > as well...
> > >
> > > T
> > >
> > > On Mon, May 6, 2024 at 2:36 PM Tamás Cservenák 
> > > wrote:
> > >
> > > > Pretty much the same story as Maven models vs Maven "core"
> (maven-core
> > in
> > > > 3.x or api-imple in 4) they don't share the same release
> lifecycle.
> > > >
> > > > SPI is not to be changed often, while we do patch releases of the
> > > plugins.
> > > > Am not saying we cannot keep SPI along with Plugins, I am just saying
> > > that
> > > > it's pointless: we will have many releases of the same thing.
> > > >
> > > > On Mon, May 6, 2024 at 2:31 PM Guillaume Nodet 
> > > wrote:
> > > >
> > > >> Le lun. 6 mai 2024 à 14:29, Tamás Cservenák  a
> > > >> écrit :
> > > >>
> > > >> > Howdy,
> > > >> >
> > > >> > IIUC you have a problem with designated G?
> > > >> > As if so, that is really irrelevant. Point is that SPI cannot
> reside
> > > >> with
> > > >> > Plugin, as they share totally different release cycles.
> > > >> >
> > > >>
> > > >> Why ?
> > > >>
> > > >>
> > > >> >
> > > >> > Second, you mention a plugin dep, that is hence available in the
> > same
> > > >> scope
> > > >> > as the plugin itself...  which is obviously not enough in some
> > cases.
> > > >> >
> > > >> > T
> > > >> >
> > > >> > On Mon, May 6, 2024 at 2:25 PM Romain Manni-Bucau <
> > > >> rmannibu...@gmail.com>
> > > >> > wrote:
> > > >> >
> > > >> > > Hi Tamas,
> > > >> > >
> > > >> > > I kind of fail to see why org.apache.maven.maven-plugin-spi
> makes
> > > >> sense
> > > >> > > instead of org.apache.maven.plugins.$pluginArtifact-spi ?
> > > >> > > My understanding is that we already have that since any plugin
> can
> > > >> > define a
> > > >> > > specific SPI in its code and get it injected from a plugin dep
> > using
> > > >> its
> > > >> > >  block - exactly like shade plugin references its
> > > >> > > transformers to be concrete.
> > > >> > > So for me nothing to create nor modify to get an old feature.
> > > >> > >
> > > >> > > Romain Manni-Bucau
> > > >> > > @rmannibucau  |  Blog
> > > >> > >  | Old Blog
> > > >> > >  | Github <
> > > >> > > https://github.com/rmannibucau> |
> > > >> > > LinkedIn  | Book
> > > >> > > <
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >> > > >
> > > >> > >
> > > >> > >
> > > >> > > Le lun. 6 mai 2024 à 14:08, Tamás Cservenák <
> ta...@cservenak.net>
> > a
> > > >> > écrit
> > > >> > > :
> > > >> > >
> > > >> > > > Howdy,
> > > >> > > >
> > > >> > > > I'd like to create a new ASF Maven git repo
> "maven-plugin-spi".
> > > >> > > >
> > > >> > > > This repository would hold SPIs as explained here
> > > >> > > >
> > > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI
> > > >> > > >
> > > >> > > > Designated G: "org.apache.maven.maven-plugin-spi"
> > > >> > > >
> > > >> > > > For now, we have two candidates to apply SPI pattern:
> > > >> > > > * maven-deploy-plugin (yet to be added)
> > > >> > > > * maven-gpg-plugin (already have it, but in unusable form, as
> it
> > > >> does
> > > >> > not
> > > >> > > > follow pattern from wiki)
> > > >> > > >
> > > >> > > > Example GAs:
> > > >> > > > org.apache.maven.maven-plugin-spi:maven-deploy-spi
> > > >> > > > org.apache.maven.maven-plugin-spi:maven-gpg-spi
> > > >> > > >
> > > >> > > > Thanks
> > > >> > > > T
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >>
> > > >> --
> > > >> 
> > > >> Guillaume Nodet

Re: [DISCUSS] Maven Plugin SPI

[Tamás Cservenák]

Sure,

Again, I am fine with having SPI artifact next to plugin consumer artifact.
All I wanted to prevent is having tens or more versions of SPI artifact
released, while in fact they are "same thing".

T

On Mon, May 6, 2024 at 3:03 PM Guillaume Nodet  wrote:

> Le lun. 6 mai 2024 à 14:38, Tamás Cservenák  a écrit
> :
>
> > lapsus: as in maven-core and maven-model SHOULD NOT share the same
> release
> > lifecycle. They DO currently.
> > Which implies that we have as many maven-model artifacts released so far
> as
> > many maven, but many of them are binary equivalent to each other.
> >
>
> What's the drawback with that ? It's much easier to handle for both the
> developper side
> and for the consumer side (they only have to upgrade a single version
> instead of two).
>
> I'm quite on the opposite side, and I'd much rather simplify our release
> cycles rather
> than going with one repo per jar...
>
>
> > That's all I wanted to prevent. Am fine with having SPI next to the
> plugin
> > as well...
> >
> > T
> >
> > On Mon, May 6, 2024 at 2:36 PM Tamás Cservenák 
> > wrote:
> >
> > > Pretty much the same story as Maven models vs Maven "core" (maven-core
> in
> > > 3.x or api-imple in 4) they don't share the same release lifecycle.
> > >
> > > SPI is not to be changed often, while we do patch releases of the
> > plugins.
> > > Am not saying we cannot keep SPI along with Plugins, I am just saying
> > that
> > > it's pointless: we will have many releases of the same thing.
> > >
> > > On Mon, May 6, 2024 at 2:31 PM Guillaume Nodet 
> > wrote:
> > >
> > >> Le lun. 6 mai 2024 à 14:29, Tamás Cservenák  a
> > >> écrit :
> > >>
> > >> > Howdy,
> > >> >
> > >> > IIUC you have a problem with designated G?
> > >> > As if so, that is really irrelevant. Point is that SPI cannot reside
> > >> with
> > >> > Plugin, as they share totally different release cycles.
> > >> >
> > >>
> > >> Why ?
> > >>
> > >>
> > >> >
> > >> > Second, you mention a plugin dep, that is hence available in the
> same
> > >> scope
> > >> > as the plugin itself...  which is obviously not enough in some
> cases.
> > >> >
> > >> > T
> > >> >
> > >> > On Mon, May 6, 2024 at 2:25 PM Romain Manni-Bucau <
> > >> rmannibu...@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > Hi Tamas,
> > >> > >
> > >> > > I kind of fail to see why org.apache.maven.maven-plugin-spi makes
> > >> sense
> > >> > > instead of org.apache.maven.plugins.$pluginArtifact-spi ?
> > >> > > My understanding is that we already have that since any plugin can
> > >> > define a
> > >> > > specific SPI in its code and get it injected from a plugin dep
> using
> > >> its
> > >> > >  block - exactly like shade plugin references its
> > >> > > transformers to be concrete.
> > >> > > So for me nothing to create nor modify to get an old feature.
> > >> > >
> > >> > > Romain Manni-Bucau
> > >> > > @rmannibucau  |  Blog
> > >> > >  | Old Blog
> > >> > >  | Github <
> > >> > > https://github.com/rmannibucau> |
> > >> > > LinkedIn  | Book
> > >> > > <
> > >> > >
> > >> >
> > >>
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >> > > >
> > >> > >
> > >> > >
> > >> > > Le lun. 6 mai 2024 à 14:08, Tamás Cservenák 
> a
> > >> > écrit
> > >> > > :
> > >> > >
> > >> > > > Howdy,
> > >> > > >
> > >> > > > I'd like to create a new ASF Maven git repo "maven-plugin-spi".
> > >> > > >
> > >> > > > This repository would hold SPIs as explained here
> > >> > > >
> > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI
> > >> > > >
> > >> > > > Designated G: "org.apache.maven.maven-plugin-spi"
> > >> > > >
> > >> > > > For now, we have two candidates to apply SPI pattern:
> > >> > > > * maven-deploy-plugin (yet to be added)
> > >> > > > * maven-gpg-plugin (already have it, but in unusable form, as it
> > >> does
> > >> > not
> > >> > > > follow pattern from wiki)
> > >> > > >
> > >> > > > Example GAs:
> > >> > > > org.apache.maven.maven-plugin-spi:maven-deploy-spi
> > >> > > > org.apache.maven.maven-plugin-spi:maven-gpg-spi
> > >> > > >
> > >> > > > Thanks
> > >> > > > T
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >>
> > >> --
> > >> 
> > >> Guillaume Nodet
> > >>
> > >
> >
>
>
> --
> 
> Guillaume Nodet
>

Re: [DISCUSS] Maven Plugin SPI

[Guillaume Nodet]

Le lun. 6 mai 2024 à 14:38, Tamás Cservenák  a écrit :

> lapsus: as in maven-core and maven-model SHOULD NOT share the same release
> lifecycle. They DO currently.
> Which implies that we have as many maven-model artifacts released so far as
> many maven, but many of them are binary equivalent to each other.
>

What's the drawback with that ? It's much easier to handle for both the
developper side
and for the consumer side (they only have to upgrade a single version
instead of two).

I'm quite on the opposite side, and I'd much rather simplify our release
cycles rather
than going with one repo per jar...


> That's all I wanted to prevent. Am fine with having SPI next to the plugin
> as well...
>
> T
>
> On Mon, May 6, 2024 at 2:36 PM Tamás Cservenák 
> wrote:
>
> > Pretty much the same story as Maven models vs Maven "core" (maven-core in
> > 3.x or api-imple in 4) they don't share the same release lifecycle.
> >
> > SPI is not to be changed often, while we do patch releases of the
> plugins.
> > Am not saying we cannot keep SPI along with Plugins, I am just saying
> that
> > it's pointless: we will have many releases of the same thing.
> >
> > On Mon, May 6, 2024 at 2:31 PM Guillaume Nodet 
> wrote:
> >
> >> Le lun. 6 mai 2024 à 14:29, Tamás Cservenák  a
> >> écrit :
> >>
> >> > Howdy,
> >> >
> >> > IIUC you have a problem with designated G?
> >> > As if so, that is really irrelevant. Point is that SPI cannot reside
> >> with
> >> > Plugin, as they share totally different release cycles.
> >> >
> >>
> >> Why ?
> >>
> >>
> >> >
> >> > Second, you mention a plugin dep, that is hence available in the same
> >> scope
> >> > as the plugin itself...  which is obviously not enough in some cases.
> >> >
> >> > T
> >> >
> >> > On Mon, May 6, 2024 at 2:25 PM Romain Manni-Bucau <
> >> rmannibu...@gmail.com>
> >> > wrote:
> >> >
> >> > > Hi Tamas,
> >> > >
> >> > > I kind of fail to see why org.apache.maven.maven-plugin-spi makes
> >> sense
> >> > > instead of org.apache.maven.plugins.$pluginArtifact-spi ?
> >> > > My understanding is that we already have that since any plugin can
> >> > define a
> >> > > specific SPI in its code and get it injected from a plugin dep using
> >> its
> >> > >  block - exactly like shade plugin references its
> >> > > transformers to be concrete.
> >> > > So for me nothing to create nor modify to get an old feature.
> >> > >
> >> > > Romain Manni-Bucau
> >> > > @rmannibucau  |  Blog
> >> > >  | Old Blog
> >> > >  | Github <
> >> > > https://github.com/rmannibucau> |
> >> > > LinkedIn  | Book
> >> > > <
> >> > >
> >> >
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >> > > >
> >> > >
> >> > >
> >> > > Le lun. 6 mai 2024 à 14:08, Tamás Cservenák  a
> >> > écrit
> >> > > :
> >> > >
> >> > > > Howdy,
> >> > > >
> >> > > > I'd like to create a new ASF Maven git repo "maven-plugin-spi".
> >> > > >
> >> > > > This repository would hold SPIs as explained here
> >> > > >
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI
> >> > > >
> >> > > > Designated G: "org.apache.maven.maven-plugin-spi"
> >> > > >
> >> > > > For now, we have two candidates to apply SPI pattern:
> >> > > > * maven-deploy-plugin (yet to be added)
> >> > > > * maven-gpg-plugin (already have it, but in unusable form, as it
> >> does
> >> > not
> >> > > > follow pattern from wiki)
> >> > > >
> >> > > > Example GAs:
> >> > > > org.apache.maven.maven-plugin-spi:maven-deploy-spi
> >> > > > org.apache.maven.maven-plugin-spi:maven-gpg-spi
> >> > > >
> >> > > > Thanks
> >> > > > T
> >> > > >
> >> > >
> >> >
> >>
> >>
> >> --
> >> 
> >> Guillaume Nodet
> >>
> >
>


-- 

Guillaume Nodet

Re: [DISCUSS] Maven Plugin SPI

[Tamás Cservenák]

Romain,

one more thing I missed to respond: you say
"plugin can define a specific SPI in its code and get it injected from a
plugin dep using its  block"

A) I hope you meant here "get it injected from a plugin dep using its
 block" :)
Since as we know, doing trickeries like using  block to set
GAV-like things, that plugin resolves on its own is BAD THING to do: Maven
itself have no knowledge about such dependencies, and it totally breaks
reactor builds, where same thing is being built, and later used as "tricky
dependency". This pattern is bad as it is.

B) If defined as , then -- obviously -- the dependency
components will share the same plugin scope, so you are still in a very
"narrow" scope, as none of the mentioned plugins are _usually_ set up as
extensions (deploy, gpg). Moreover, remember the "early deploy at end"
implementation, that required m-deploy-p to be made into extension to make
the feature work... it just caused a ton of confusion to users.

T

On Mon, May 6, 2024 at 2:25 PM Romain Manni-Bucau 
wrote:

> Hi Tamas,
>
> I kind of fail to see why org.apache.maven.maven-plugin-spi makes sense
> instead of org.apache.maven.plugins.$pluginArtifact-spi ?
> My understanding is that we already have that since any plugin can define a
> specific SPI in its code and get it injected from a plugin dep using its
>  block - exactly like shade plugin references its
> transformers to be concrete.
> So for me nothing to create nor modify to get an old feature.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 6 mai 2024 à 14:08, Tamás Cservenák  a écrit
> :
>
> > Howdy,
> >
> > I'd like to create a new ASF Maven git repo "maven-plugin-spi".
> >
> > This repository would hold SPIs as explained here
> > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI
> >
> > Designated G: "org.apache.maven.maven-plugin-spi"
> >
> > For now, we have two candidates to apply SPI pattern:
> > * maven-deploy-plugin (yet to be added)
> > * maven-gpg-plugin (already have it, but in unusable form, as it does not
> > follow pattern from wiki)
> >
> > Example GAs:
> > org.apache.maven.maven-plugin-spi:maven-deploy-spi
> > org.apache.maven.maven-plugin-spi:maven-gpg-spi
> >
> > Thanks
> > T
> >
>

Re: [DISCUSS] Maven Plugin SPI

[Christoph Läubrich]

Hi Tamas,

I'm specifically asking because Tycho has already a plugin-spi support 
we use to a great extent, so if there would be a general usable solution 
that would be great I even asked many times for it but always got "use 
an extension" so I wonder what changed the mind of maven-devs or if it 
will be just another thing exclusive to "maven-core-plugins" or can 
other reuse that (how?). And if others can reuse it, why have a 
dedicated repository and not use the repository of the plugin that 
offers the spi?


Am 06.05.24 um 14:08 schrieb Tamás Cservenák:

Howdy,

I'd like to create a new ASF Maven git repo "maven-plugin-spi".

This repository would hold SPIs as explained here
https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI

Designated G: "org.apache.maven.maven-plugin-spi"

For now, we have two candidates to apply SPI pattern:
* maven-deploy-plugin (yet to be added)
* maven-gpg-plugin (already have it, but in unusable form, as it does not
follow pattern from wiki)

Example GAs:
org.apache.maven.maven-plugin-spi:maven-deploy-spi
org.apache.maven.maven-plugin-spi:maven-gpg-spi

Thanks
T



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

Re: [DISCUSS] Maven Plugin SPI

[Tamás Cservenák]

lapsus: as in maven-core and maven-model SHOULD NOT share the same release
lifecycle. They DO currently.
Which implies that we have as many maven-model artifacts released so far as
many maven, but many of them are binary equivalent to each other.
That's all I wanted to prevent. Am fine with having SPI next to the plugin
as well...

T

On Mon, May 6, 2024 at 2:36 PM Tamás Cservenák  wrote:

> Pretty much the same story as Maven models vs Maven "core" (maven-core in
> 3.x or api-imple in 4) they don't share the same release lifecycle.
>
> SPI is not to be changed often, while we do patch releases of the plugins.
> Am not saying we cannot keep SPI along with Plugins, I am just saying that
> it's pointless: we will have many releases of the same thing.
>
> On Mon, May 6, 2024 at 2:31 PM Guillaume Nodet  wrote:
>
>> Le lun. 6 mai 2024 à 14:29, Tamás Cservenák  a
>> écrit :
>>
>> > Howdy,
>> >
>> > IIUC you have a problem with designated G?
>> > As if so, that is really irrelevant. Point is that SPI cannot reside
>> with
>> > Plugin, as they share totally different release cycles.
>> >
>>
>> Why ?
>>
>>
>> >
>> > Second, you mention a plugin dep, that is hence available in the same
>> scope
>> > as the plugin itself...  which is obviously not enough in some cases.
>> >
>> > T
>> >
>> > On Mon, May 6, 2024 at 2:25 PM Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> > wrote:
>> >
>> > > Hi Tamas,
>> > >
>> > > I kind of fail to see why org.apache.maven.maven-plugin-spi makes
>> sense
>> > > instead of org.apache.maven.plugins.$pluginArtifact-spi ?
>> > > My understanding is that we already have that since any plugin can
>> > define a
>> > > specific SPI in its code and get it injected from a plugin dep using
>> its
>> > >  block - exactly like shade plugin references its
>> > > transformers to be concrete.
>> > > So for me nothing to create nor modify to get an old feature.
>> > >
>> > > Romain Manni-Bucau
>> > > @rmannibucau  |  Blog
>> > >  | Old Blog
>> > >  | Github <
>> > > https://github.com/rmannibucau> |
>> > > LinkedIn  | Book
>> > > <
>> > >
>> >
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> > > >
>> > >
>> > >
>> > > Le lun. 6 mai 2024 à 14:08, Tamás Cservenák  a
>> > écrit
>> > > :
>> > >
>> > > > Howdy,
>> > > >
>> > > > I'd like to create a new ASF Maven git repo "maven-plugin-spi".
>> > > >
>> > > > This repository would hold SPIs as explained here
>> > > > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI
>> > > >
>> > > > Designated G: "org.apache.maven.maven-plugin-spi"
>> > > >
>> > > > For now, we have two candidates to apply SPI pattern:
>> > > > * maven-deploy-plugin (yet to be added)
>> > > > * maven-gpg-plugin (already have it, but in unusable form, as it
>> does
>> > not
>> > > > follow pattern from wiki)
>> > > >
>> > > > Example GAs:
>> > > > org.apache.maven.maven-plugin-spi:maven-deploy-spi
>> > > > org.apache.maven.maven-plugin-spi:maven-gpg-spi
>> > > >
>> > > > Thanks
>> > > > T
>> > > >
>> > >
>> >
>>
>>
>> --
>> 
>> Guillaume Nodet
>>
>

Re: [DISCUSS] Maven Plugin SPI

[Tamás Cservenák]

Pretty much the same story as Maven models vs Maven "core" (maven-core in
3.x or api-imple in 4) they don't share the same release lifecycle.

SPI is not to be changed often, while we do patch releases of the plugins.
Am not saying we cannot keep SPI along with Plugins, I am just saying that
it's pointless: we will have many releases of the same thing.

On Mon, May 6, 2024 at 2:31 PM Guillaume Nodet  wrote:

> Le lun. 6 mai 2024 à 14:29, Tamás Cservenák  a écrit
> :
>
> > Howdy,
> >
> > IIUC you have a problem with designated G?
> > As if so, that is really irrelevant. Point is that SPI cannot reside with
> > Plugin, as they share totally different release cycles.
> >
>
> Why ?
>
>
> >
> > Second, you mention a plugin dep, that is hence available in the same
> scope
> > as the plugin itself...  which is obviously not enough in some cases.
> >
> > T
> >
> > On Mon, May 6, 2024 at 2:25 PM Romain Manni-Bucau  >
> > wrote:
> >
> > > Hi Tamas,
> > >
> > > I kind of fail to see why org.apache.maven.maven-plugin-spi makes sense
> > > instead of org.apache.maven.plugins.$pluginArtifact-spi ?
> > > My understanding is that we already have that since any plugin can
> > define a
> > > specific SPI in its code and get it injected from a plugin dep using
> its
> > >  block - exactly like shade plugin references its
> > > transformers to be concrete.
> > > So for me nothing to create nor modify to get an old feature.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le lun. 6 mai 2024 à 14:08, Tamás Cservenák  a
> > écrit
> > > :
> > >
> > > > Howdy,
> > > >
> > > > I'd like to create a new ASF Maven git repo "maven-plugin-spi".
> > > >
> > > > This repository would hold SPIs as explained here
> > > > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI
> > > >
> > > > Designated G: "org.apache.maven.maven-plugin-spi"
> > > >
> > > > For now, we have two candidates to apply SPI pattern:
> > > > * maven-deploy-plugin (yet to be added)
> > > > * maven-gpg-plugin (already have it, but in unusable form, as it does
> > not
> > > > follow pattern from wiki)
> > > >
> > > > Example GAs:
> > > > org.apache.maven.maven-plugin-spi:maven-deploy-spi
> > > > org.apache.maven.maven-plugin-spi:maven-gpg-spi
> > > >
> > > > Thanks
> > > > T
> > > >
> > >
> >
>
>
> --
> 
> Guillaume Nodet
>

Re: [DISCUSS] Maven Plugin SPI

[Guillaume Nodet]

Le lun. 6 mai 2024 à 14:29, Tamás Cservenák  a écrit :

> Howdy,
>
> IIUC you have a problem with designated G?
> As if so, that is really irrelevant. Point is that SPI cannot reside with
> Plugin, as they share totally different release cycles.
>

Why ?


>
> Second, you mention a plugin dep, that is hence available in the same scope
> as the plugin itself...  which is obviously not enough in some cases.
>
> T
>
> On Mon, May 6, 2024 at 2:25 PM Romain Manni-Bucau 
> wrote:
>
> > Hi Tamas,
> >
> > I kind of fail to see why org.apache.maven.maven-plugin-spi makes sense
> > instead of org.apache.maven.plugins.$pluginArtifact-spi ?
> > My understanding is that we already have that since any plugin can
> define a
> > specific SPI in its code and get it injected from a plugin dep using its
> >  block - exactly like shade plugin references its
> > transformers to be concrete.
> > So for me nothing to create nor modify to get an old feature.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le lun. 6 mai 2024 à 14:08, Tamás Cservenák  a
> écrit
> > :
> >
> > > Howdy,
> > >
> > > I'd like to create a new ASF Maven git repo "maven-plugin-spi".
> > >
> > > This repository would hold SPIs as explained here
> > > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI
> > >
> > > Designated G: "org.apache.maven.maven-plugin-spi"
> > >
> > > For now, we have two candidates to apply SPI pattern:
> > > * maven-deploy-plugin (yet to be added)
> > > * maven-gpg-plugin (already have it, but in unusable form, as it does
> not
> > > follow pattern from wiki)
> > >
> > > Example GAs:
> > > org.apache.maven.maven-plugin-spi:maven-deploy-spi
> > > org.apache.maven.maven-plugin-spi:maven-gpg-spi
> > >
> > > Thanks
> > > T
> > >
> >
>


-- 

Guillaume Nodet

Re: [DISCUSS] Maven Plugin SPI

[Guillaume Nodet]

I also don't really see the value of having all SPI in a single repo.
It seems easier to have each SPI inside the repository of each maven plugin
instead.

Le lun. 6 mai 2024 à 14:25, Romain Manni-Bucau  a
écrit :

> Hi Tamas,
>
> I kind of fail to see why org.apache.maven.maven-plugin-spi makes sense
> instead of org.apache.maven.plugins.$pluginArtifact-spi ?
> My understanding is that we already have that since any plugin can define a
> specific SPI in its code and get it injected from a plugin dep using its
>  block - exactly like shade plugin references its
> transformers to be concrete.
> So for me nothing to create nor modify to get an old feature.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 6 mai 2024 à 14:08, Tamás Cservenák  a écrit
> :
>
> > Howdy,
> >
> > I'd like to create a new ASF Maven git repo "maven-plugin-spi".
> >
> > This repository would hold SPIs as explained here
> > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI
> >
> > Designated G: "org.apache.maven.maven-plugin-spi"
> >
> > For now, we have two candidates to apply SPI pattern:
> > * maven-deploy-plugin (yet to be added)
> > * maven-gpg-plugin (already have it, but in unusable form, as it does not
> > follow pattern from wiki)
> >
> > Example GAs:
> > org.apache.maven.maven-plugin-spi:maven-deploy-spi
> > org.apache.maven.maven-plugin-spi:maven-gpg-spi
> >
> > Thanks
> > T
> >
>


-- 

Guillaume Nodet

Re: [DISCUSS] Maven Plugin SPI

[Tamás Cservenák]

Howdy,

IIUC you have a problem with designated G?
As if so, that is really irrelevant. Point is that SPI cannot reside with
Plugin, as they share totally different release cycles.

Second, you mention a plugin dep, that is hence available in the same scope
as the plugin itself...  which is obviously not enough in some cases.

T

On Mon, May 6, 2024 at 2:25 PM Romain Manni-Bucau 
wrote:

> Hi Tamas,
>
> I kind of fail to see why org.apache.maven.maven-plugin-spi makes sense
> instead of org.apache.maven.plugins.$pluginArtifact-spi ?
> My understanding is that we already have that since any plugin can define a
> specific SPI in its code and get it injected from a plugin dep using its
>  block - exactly like shade plugin references its
> transformers to be concrete.
> So for me nothing to create nor modify to get an old feature.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 6 mai 2024 à 14:08, Tamás Cservenák  a écrit
> :
>
> > Howdy,
> >
> > I'd like to create a new ASF Maven git repo "maven-plugin-spi".
> >
> > This repository would hold SPIs as explained here
> > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI
> >
> > Designated G: "org.apache.maven.maven-plugin-spi"
> >
> > For now, we have two candidates to apply SPI pattern:
> > * maven-deploy-plugin (yet to be added)
> > * maven-gpg-plugin (already have it, but in unusable form, as it does not
> > follow pattern from wiki)
> >
> > Example GAs:
> > org.apache.maven.maven-plugin-spi:maven-deploy-spi
> > org.apache.maven.maven-plugin-spi:maven-gpg-spi
> >
> > Thanks
> > T
> >
>

Re: [DISCUSS] Maven Plugin SPI

[Romain Manni-Bucau]

Hi Tamas,

I kind of fail to see why org.apache.maven.maven-plugin-spi makes sense
instead of org.apache.maven.plugins.$pluginArtifact-spi ?
My understanding is that we already have that since any plugin can define a
specific SPI in its code and get it injected from a plugin dep using its
 block - exactly like shade plugin references its
transformers to be concrete.
So for me nothing to create nor modify to get an old feature.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 6 mai 2024 à 14:08, Tamás Cservenák  a écrit :

> Howdy,
>
> I'd like to create a new ASF Maven git repo "maven-plugin-spi".
>
> This repository would hold SPIs as explained here
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI
>
> Designated G: "org.apache.maven.maven-plugin-spi"
>
> For now, we have two candidates to apply SPI pattern:
> * maven-deploy-plugin (yet to be added)
> * maven-gpg-plugin (already have it, but in unusable form, as it does not
> follow pattern from wiki)
>
> Example GAs:
> org.apache.maven.maven-plugin-spi:maven-deploy-spi
> org.apache.maven.maven-plugin-spi:maven-gpg-spi
>
> Thanks
> T
>

[DISCUSS] Maven Plugin SPI

[Tamás Cservenák]

Howdy,

I'd like to create a new ASF Maven git repo "maven-plugin-spi".

This repository would hold SPIs as explained here
https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI

Designated G: "org.apache.maven.maven-plugin-spi"

For now, we have two candidates to apply SPI pattern:
* maven-deploy-plugin (yet to be added)
* maven-gpg-plugin (already have it, but in unusable form, as it does not
follow pattern from wiki)

Example GAs:
org.apache.maven.maven-plugin-spi:maven-deploy-spi
org.apache.maven.maven-plugin-spi:maven-gpg-spi

Thanks
T

Re: [DISCUSS] Maven3 and Maven4 support split

[Tamás Cservenák]

Romain,

You can look at this change (which I did, for plugin testing) just like
resolver-1.9.x branch: a "stable" release of testing for 3.x plugins is
very desperately needed.
Same thing for maven-plugin-plugin. So yes, this is kinda the b) option: a
Maven4 plugin cannot be built (m-p-p or tested m-p-t) with Maven3 tools and
Maven3.

As for doing this for plugins (all of them) is open for debate.

T



On Mon, May 6, 2024 at 12:31 PM Romain Manni-Bucau 
wrote:

> Hi Tamas,
>
> If the impact is to prevent to build a maven 3 (original setup version or
> CI version for ex) with maven 4 (local version for ex) then I think it
> violates the contract we had for maven 4 and I'd really like it to not
> happen.
> If it is the opposite (a maven 4 based/native project can't be ran with
> maven 3) then +1.
> What I'd really don't want to see is to have to maintain 2 branches for all
> plugins for the coming ~5 years.
> If *really* an issue I'd prefer we write a migration project (openrewrite
> like - probably without openrewrite technically) to just write the maven 4
> project and make it maven 3 friendly automatically (can be a x-maven-plugin
> downloading x-v3 or x-v4 subartifact for the runtime, not sexy internally
> but very smooth in terms of usage).
>
> Best,
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 6 mai 2024 à 12:14, Tamás Cservenák  a écrit
> :
>
> > Howdy,
> >
> > my pain point was plugin-testing-harness 3.3.0 that is really ancient,
> > while master of it was mixing maven3 and maven4 support... so I went to
> > split things.
> >
> > IMO we need to split (like maven-3.x and master branch) for maven 3 and
> > maven 4 support, as there is really no need to support "both", as in case
> > of plugins, they are "this or that", they cannot be maven3 and maven4 at
> > the same time.
> >
> > Hence, I started with maven-plugin-testing:
> > https://github.com/apache/maven-plugin-testing/tree/maven-3.x
> >
> > Please eyeball and would like to prepare a 3.4.0 release of it soon.
> >
> > By the way, same should be done in maven-plugin-plugin (no need to
> support
> > creation of maven3 and maven4 plugins at the same time)... and maybe same
> > pattern (using branches maven-3.x and master for 3 and 4) should be
> applied
> > to all plugins?
> >
> > Thanks
> > T
> >
>

Re: [DISCUSS] Maven3 and Maven4 support split

[Romain Manni-Bucau]

Hi Tamas,

If the impact is to prevent to build a maven 3 (original setup version or
CI version for ex) with maven 4 (local version for ex) then I think it
violates the contract we had for maven 4 and I'd really like it to not
happen.
If it is the opposite (a maven 4 based/native project can't be ran with
maven 3) then +1.
What I'd really don't want to see is to have to maintain 2 branches for all
plugins for the coming ~5 years.
If *really* an issue I'd prefer we write a migration project (openrewrite
like - probably without openrewrite technically) to just write the maven 4
project and make it maven 3 friendly automatically (can be a x-maven-plugin
downloading x-v3 or x-v4 subartifact for the runtime, not sexy internally
but very smooth in terms of usage).

Best,
Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 6 mai 2024 à 12:14, Tamás Cservenák  a écrit :

> Howdy,
>
> my pain point was plugin-testing-harness 3.3.0 that is really ancient,
> while master of it was mixing maven3 and maven4 support... so I went to
> split things.
>
> IMO we need to split (like maven-3.x and master branch) for maven 3 and
> maven 4 support, as there is really no need to support "both", as in case
> of plugins, they are "this or that", they cannot be maven3 and maven4 at
> the same time.
>
> Hence, I started with maven-plugin-testing:
> https://github.com/apache/maven-plugin-testing/tree/maven-3.x
>
> Please eyeball and would like to prepare a 3.4.0 release of it soon.
>
> By the way, same should be done in maven-plugin-plugin (no need to support
> creation of maven3 and maven4 plugins at the same time)... and maybe same
> pattern (using branches maven-3.x and master for 3 and 4) should be applied
> to all plugins?
>
> Thanks
> T
>

Re: Quo Vadis Maven?

[Tamás Cservenák]

Btw, I feel really strange to have to explain to a long term maven
contributor, that he can do maven release whenever he feels so

T

On Mon, May 6, 2024 at 11:59 AM Tamás Cservenák  wrote:

> Howdy,
>
> I think you reversed the question... 3.9.7 was done and ready to go until
> you stepped in.
>
> IMHO the real question is:
> Is your issue (using overloaded methods in mojo config) really so urgent
> to halt 3.9.7 release?
> What is the problem with doing 3.9.8 maybe even two weeks later?
>
>
> Thanks
> T
>
> On Mon, May 6, 2024 at 7:45 AM Olivier Lamy  wrote:
>
>> Is 3.9.7 really so urgent?
>> Maybe we can wait a couple of days.
>> I have been asking the sisu dev mailing list for a release.
>> This should not be too long.
>> I can see you are in the committers list
>> (https://projects.eclipse.org/projects/technology.sisu/who) with
>> Konrad so maybe you can help to expedite this?
>>
>> regards
>> Olivier
>>
>>
>> On Sun, 5 May 2024 at 21:05, Tamás Cservenák  wrote:
>> >
>> > Howdy,
>> >
>> > Maven 3.9.7 was ready to be released 3 days ago and contains multiple
>> fixes
>> > contributed by non committers.
>> >
>> > MNG-8116 was added 2 days ago. I really see no reason to be blocked, to
>> > "stop and wait" for a bugfix, as we can always spin 3.9.8.
>> > Releases are cheap, and can be done whenever we (anyone of us) feels
>> right
>> > to do so...
>> >
>> > 3.9.7 is not the "last Maven 3.9.x" or anything like that, to have a
>> "now
>> > or never" situation. Just spin 3.9.8 whenever you think is ready.
>> >
>> > My 5 cents
>> > T
>> >
>> > On Sun, May 5, 2024 at 2:14 AM Olivier Lamy  wrote:
>> >
>> > > Hi
>> > > Can we please integrate
>> https://issues.apache.org/jira/browse/MNG-8116
>> > > The fix is ready and really simple.
>> > >
>> > > thanks
>> > > Olivier
>> > >
>> > > On Wed, 24 Apr 2024 at 07:12, Tamás Cservenák 
>> wrote:
>> > > >
>> > > > Howdy,
>> > > >
>> > > > This is just a short newsflash about upcoming planned releases
>> related to
>> > > > Maven.
>> > > >
>> > > > Recently we got a huge spike in plugin releases, with various fixes
>> and
>> > > > improvements. I will not enumerate all of them here, just use `mvn
>> > > > versions:display-plugin-updates` to pick them up ;)
>> > > > (and more plugins to come).
>> > > >
>> > > > What I do want to share is about our upcoming Maven releases...
>> > > >
>> > > > Maven 3.9.7 is nearing (read: coming soon), and will have an
>> important
>> > > > Resolver update and other important fixes. Most importantly, the
>> > > file-locks
>> > > > are getting nice improvement (feedback VERY welcome).
>> > > >
>> > > > Maven 3.9.7 issues:
>> > > >
>> > >
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.7
>> > > >
>> > > > Resolver 1.9.19 issues (mostly bug fixes):
>> > > >
>> > >
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19
>> > > >
>> > > > At the same time, we plan to release Maven Daemon (m39) as well, to
>> have
>> > > it
>> > > > aligned with Maven 3,9,7: with many bug fixes and
>> improvements/alignments
>> > > > to "how Maven 3 behave". Our goal is to make the two (mvn and mvnd)
>> > > > interchangeable on workstations.
>> > > >
>> > > > Next, Maven 4 is turning beta, so the next release will be beta1!
>> And
>> > > > again, same thing for Maven Damon (m40), we will have a release
>> that will
>> > > > include Maven 4 beta-1.
>> > > >
>> > > > Maven 4 beta-1
>> > > >
>> > >
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-beta-1
>> > > >
>> > > > Resolver 2.0.0 (currently alpha-11, will become beta after Maven4
>> beta-1
>> > > > release):
>> > > >
>> > >
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%202.0.0-alpha-11
>> > > >
>> > > > Keep your eyes on our upcoming releases,
>> > > > and have fun!
>> > > > - The Apache Maven team
>> > >
>> > > -
>> > > 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
>>
>>

Re: Quo Vadis Maven?

[Olivier Lamy]

if you think it's urgent do whatever you want..

On Mon, 6 May 2024 at 20:01, Tamás Cservenák  wrote:
>
> Howdy,
>
> I think you reversed the question... 3.9.7 was done and ready to go until
> you stepped in.
>
> IMHO the real question is:
> Is your issue (using overloaded methods in mojo config) really so urgent to
> halt 3.9.7 release?
> What is the problem with doing 3.9.8 maybe even two weeks later?
>
>
> Thanks
> T
>
> On Mon, May 6, 2024 at 7:45 AM Olivier Lamy  wrote:
>
> > Is 3.9.7 really so urgent?
> > Maybe we can wait a couple of days.
> > I have been asking the sisu dev mailing list for a release.
> > This should not be too long.
> > I can see you are in the committers list
> > (https://projects.eclipse.org/projects/technology.sisu/who) with
> > Konrad so maybe you can help to expedite this?
> >
> > regards
> > Olivier
> >
> >
> > On Sun, 5 May 2024 at 21:05, Tamás Cservenák  wrote:
> > >
> > > Howdy,
> > >
> > > Maven 3.9.7 was ready to be released 3 days ago and contains multiple
> > fixes
> > > contributed by non committers.
> > >
> > > MNG-8116 was added 2 days ago. I really see no reason to be blocked, to
> > > "stop and wait" for a bugfix, as we can always spin 3.9.8.
> > > Releases are cheap, and can be done whenever we (anyone of us) feels
> > right
> > > to do so...
> > >
> > > 3.9.7 is not the "last Maven 3.9.x" or anything like that, to have a "now
> > > or never" situation. Just spin 3.9.8 whenever you think is ready.
> > >
> > > My 5 cents
> > > T
> > >
> > > On Sun, May 5, 2024 at 2:14 AM Olivier Lamy  wrote:
> > >
> > > > Hi
> > > > Can we please integrate https://issues.apache.org/jira/browse/MNG-8116
> > > > The fix is ready and really simple.
> > > >
> > > > thanks
> > > > Olivier
> > > >
> > > > On Wed, 24 Apr 2024 at 07:12, Tamás Cservenák 
> > wrote:
> > > > >
> > > > > Howdy,
> > > > >
> > > > > This is just a short newsflash about upcoming planned releases
> > related to
> > > > > Maven.
> > > > >
> > > > > Recently we got a huge spike in plugin releases, with various fixes
> > and
> > > > > improvements. I will not enumerate all of them here, just use `mvn
> > > > > versions:display-plugin-updates` to pick them up ;)
> > > > > (and more plugins to come).
> > > > >
> > > > > What I do want to share is about our upcoming Maven releases...
> > > > >
> > > > > Maven 3.9.7 is nearing (read: coming soon), and will have an
> > important
> > > > > Resolver update and other important fixes. Most importantly, the
> > > > file-locks
> > > > > are getting nice improvement (feedback VERY welcome).
> > > > >
> > > > > Maven 3.9.7 issues:
> > > > >
> > > >
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.7
> > > > >
> > > > > Resolver 1.9.19 issues (mostly bug fixes):
> > > > >
> > > >
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19
> > > > >
> > > > > At the same time, we plan to release Maven Daemon (m39) as well, to
> > have
> > > > it
> > > > > aligned with Maven 3,9,7: with many bug fixes and
> > improvements/alignments
> > > > > to "how Maven 3 behave". Our goal is to make the two (mvn and mvnd)
> > > > > interchangeable on workstations.
> > > > >
> > > > > Next, Maven 4 is turning beta, so the next release will be beta1! And
> > > > > again, same thing for Maven Damon (m40), we will have a release that
> > will
> > > > > include Maven 4 beta-1.
> > > > >
> > > > > Maven 4 beta-1
> > > > >
> > > >
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-beta-1
> > > > >
> > > > > Resolver 2.0.0 (currently alpha-11, will become beta after Maven4
> > beta-1
> > > > > release):
> > > > >
> > > >
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%202.0.0-alpha-11
> > > > >
> > > > > Keep your eyes on our upcoming releases,
> > > > > and have fun!
> > > > > - The Apache Maven team
> > > >
> > > > -
> > > > 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

[DISCUSS] Maven3 and Maven4 support split

[Tamás Cservenák]

Howdy,

my pain point was plugin-testing-harness 3.3.0 that is really ancient,
while master of it was mixing maven3 and maven4 support... so I went to
split things.

IMO we need to split (like maven-3.x and master branch) for maven 3 and
maven 4 support, as there is really no need to support "both", as in case
of plugins, they are "this or that", they cannot be maven3 and maven4 at
the same time.

Hence, I started with maven-plugin-testing:
https://github.com/apache/maven-plugin-testing/tree/maven-3.x

Please eyeball and would like to prepare a 3.4.0 release of it soon.

By the way, same should be done in maven-plugin-plugin (no need to support
creation of maven3 and maven4 plugins at the same time)... and maybe same
pattern (using branches maven-3.x and master for 3 and 4) should be applied
to all plugins?

Thanks
T

Re: Quo Vadis Maven?

[Tamás Cservenák]

Howdy,

I think you reversed the question... 3.9.7 was done and ready to go until
you stepped in.

IMHO the real question is:
Is your issue (using overloaded methods in mojo config) really so urgent to
halt 3.9.7 release?
What is the problem with doing 3.9.8 maybe even two weeks later?


Thanks
T

On Mon, May 6, 2024 at 7:45 AM Olivier Lamy  wrote:

> Is 3.9.7 really so urgent?
> Maybe we can wait a couple of days.
> I have been asking the sisu dev mailing list for a release.
> This should not be too long.
> I can see you are in the committers list
> (https://projects.eclipse.org/projects/technology.sisu/who) with
> Konrad so maybe you can help to expedite this?
>
> regards
> Olivier
>
>
> On Sun, 5 May 2024 at 21:05, Tamás Cservenák  wrote:
> >
> > Howdy,
> >
> > Maven 3.9.7 was ready to be released 3 days ago and contains multiple
> fixes
> > contributed by non committers.
> >
> > MNG-8116 was added 2 days ago. I really see no reason to be blocked, to
> > "stop and wait" for a bugfix, as we can always spin 3.9.8.
> > Releases are cheap, and can be done whenever we (anyone of us) feels
> right
> > to do so...
> >
> > 3.9.7 is not the "last Maven 3.9.x" or anything like that, to have a "now
> > or never" situation. Just spin 3.9.8 whenever you think is ready.
> >
> > My 5 cents
> > T
> >
> > On Sun, May 5, 2024 at 2:14 AM Olivier Lamy  wrote:
> >
> > > Hi
> > > Can we please integrate https://issues.apache.org/jira/browse/MNG-8116
> > > The fix is ready and really simple.
> > >
> > > thanks
> > > Olivier
> > >
> > > On Wed, 24 Apr 2024 at 07:12, Tamás Cservenák 
> wrote:
> > > >
> > > > Howdy,
> > > >
> > > > This is just a short newsflash about upcoming planned releases
> related to
> > > > Maven.
> > > >
> > > > Recently we got a huge spike in plugin releases, with various fixes
> and
> > > > improvements. I will not enumerate all of them here, just use `mvn
> > > > versions:display-plugin-updates` to pick them up ;)
> > > > (and more plugins to come).
> > > >
> > > > What I do want to share is about our upcoming Maven releases...
> > > >
> > > > Maven 3.9.7 is nearing (read: coming soon), and will have an
> important
> > > > Resolver update and other important fixes. Most importantly, the
> > > file-locks
> > > > are getting nice improvement (feedback VERY welcome).
> > > >
> > > > Maven 3.9.7 issues:
> > > >
> > >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.7
> > > >
> > > > Resolver 1.9.19 issues (mostly bug fixes):
> > > >
> > >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19
> > > >
> > > > At the same time, we plan to release Maven Daemon (m39) as well, to
> have
> > > it
> > > > aligned with Maven 3,9,7: with many bug fixes and
> improvements/alignments
> > > > to "how Maven 3 behave". Our goal is to make the two (mvn and mvnd)
> > > > interchangeable on workstations.
> > > >
> > > > Next, Maven 4 is turning beta, so the next release will be beta1! And
> > > > again, same thing for Maven Damon (m40), we will have a release that
> will
> > > > include Maven 4 beta-1.
> > > >
> > > > Maven 4 beta-1
> > > >
> > >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-beta-1
> > > >
> > > > Resolver 2.0.0 (currently alpha-11, will become beta after Maven4
> beta-1
> > > > release):
> > > >
> > >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%202.0.0-alpha-11
> > > >
> > > > Keep your eyes on our upcoming releases,
> > > > and have fun!
> > > > - The Apache Maven team
> > >
> > > -
> > > 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
>
>

Re: [VOTE] Release Maven Site Plugin version 4.0.0-M14

[Michael Osipov]

On 2024/05/06 06:57:00 Hervé Boutemy wrote:
> +1
> 
> Reproducible Build ok: reference build done with JDK 8 on Windows and umask = 
> 022 (parent POM not upgraded, which should remove the umask requirement)

Parent upgrade is planned for the next release train.

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

Re: [VOTE] Release Maven Site Plugin version 4.0.0-M14

[Michael Osipov]

On 2024/05/06 07:44:43 Konrad Windszus wrote:
> Hi,
> There was a longer discussion in 
> https://www.mail-archive.com/dev@maven.apache.org/msg132078.html (for some 
> reason cannot find the thread in 
> https://lists.apache.org/list.html?dev@maven.apache.org) and we kind of came 
> to an agreement to reserve plugin major version 4 for plugins leveraging 
> Maven 4 API.
> So should we rename this to m-site-p 3.13.x?
> This requires adaptation in the source code with regards to the since javadoc 
> tag.
> WDYT?

This is something I already thought of and will write a [DISCUSS] email in a 
couple of weeks for my Doxia 2.0.0 announcement proposal with other devs. This 
will include the question you have raised. For now, I'd like to keep it as-is 
until this discussion has been started.

M

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

Re: [VOTE] Release Maven Site Plugin version 4.0.0-M14

[Konrad Windszus]

Hi,
There was a longer discussion in 
https://www.mail-archive.com/dev@maven.apache.org/msg132078.html (for some 
reason cannot find the thread in 
https://lists.apache.org/list.html?dev@maven.apache.org) and we kind of came to 
an agreement to reserve plugin major version 4 for plugins leveraging Maven 4 
API.
So should we rename this to m-site-p 3.13.x?
This requires adaptation in the source code with regards to the since javadoc 
tag.
WDYT?
Konrad

> On 5. May 2024, at 21:29, Michael Osipov  wrote:
> 
> Hi,
> 
> we solved 4 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317923=12354123
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSITE%20AND%20resolution%20%3D%20Unresolved
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2109/
> https://repository.apache.org/content/repositories/maven-2109/org/apache/maven/plugins/maven-site-plugin/4.0.0-M14/maven-site-plugin-4.0.0-M14-source-release.zip
> 
> Source release checksum(s):
> maven-site-plugin-4.0.0-M14-source-release.zip
> sha512: 
> cf9b896e1bc10b0bb81ded66f343e478da4da21300d10ac586ac08a8640bc7c11f25ff49d8f443c12e98011608c5d2db308d9b0b7ec1d9378d84616712b5b660
> 
> Staging site:
> https://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Re: [VOTE] Release Maven Site Plugin version 4.0.0-M14

[Hervé Boutemy]

+1

Reproducible Build ok: reference build done with JDK 8 on Windows and umask = 
022 (parent POM not upgraded, which should remove the umask requirement)

Regards,

Hervé

Le dimanche 5 mai 2024, 21:29:12 CEST Michael Osipov a écrit :
> Hi,
> 
> we solved 4 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317923
> rsion=12354123
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSITE%20AND%20res
> olution%20%3D%20Unresolved
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2109/
> https://repository.apache.org/content/repositories/maven-2109/org/apache/mav
> en/plugins/maven-site-plugin/4.0.0-M14/maven-site-plugin-4.0.0-M14-source-re
> lease.zip
> 
> Source release checksum(s):
> maven-site-plugin-4.0.0-M14-source-release.zip
> sha512:
> cf9b896e1bc10b0bb81ded66f343e478da4da21300d10ac586ac08a8640bc7c11f25ff49d8f4
> 43c12e98011608c5d2db308d9b0b7ec1d9378d84616712b5b660
> 
> Staging site:
> https://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -
> 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