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