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 <rmannibu...@gmail.com> wrote: > Le lun. 6 mai 2024 à 16:00, Tamás Cservenák <ta...@cservenak.net> 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) > > > > Right....which 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 <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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
