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 <rmannibu...@gmail.com>
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 <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 6 mai 2024 à 15:48, Tamás Cservenák <ta...@cservenak.net> 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 <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le lun. 6 mai 2024 à 15:36, Tamás Cservenák <ta...@cservenak.net> 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)
> > > > > > * 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
> > > > >
> > > > >
> > > >
> > >
> >
>

Reply via email to