Re: [DISCUSS] Maven Plugin SPI

[Christoph Läubrich]

I agree with Tamás here, that's a really worse pattern, even more worse, 
if the users configures the other mojo (deploy plugin in this case) and 
it seems having no effect gives you the perfect WTF moments...


I also agree with the C argument, if I want to influence one aspect 
its unlikley usefull to reimplment *everything*.


By the way the only thing needed to implement such thing would be that a 
jar can promote itself as being "an spi" and therefore exporting its 
packages to everyone using that jar, as such SPI implementations are 
tighly coupled anyway it would even be fair to require a 1:1 match (such 
SPI will likley seldom change if at all).


Currently Tycho does that by require the user to enable it as a build 
extension and export the SPI jar, then there is a little helper class to 
call the SPI in the realm of the plugin, so if this helper would be part 
of maven core and the jar itself could "export" it would all be done.


Am 06.05.24 um 16:23 schrieb 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 





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 

Re: [DISCUSS] Maven Plugin SPI

[Christoph Läubrich]

has another drawback that there is literally no way to further 
customize/configure it so it is only suitable for trivial cases.


This would also not work when using more than one SPI.

One good example for OSGi use case (maybe others as well) is the maven 
jar plugin, as there is no way to just add some new headers to the 
manifest without either special configuration or hacks (e.g. extensions 
or custom packing types), having a "plugin-spi" that gets wired only by 
adding another Mojo allowing to compute additional headers would be the 
natural solution.



Am 06.05.24 um 15:02 schrieb 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







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

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

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
>