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

[Tamás Cservenák]

Howdy,

Did anyone look at or maybe even tried MDK?

Thanks
T

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

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

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

[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