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 <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:20, Guillaume Nodet <gno...@apache.org> 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 <ta...@cservenak.net> 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 <gno...@apache.org> > wrote: > > > > > Le lun. 6 mai 2024 à 14:38, Tamás Cservenák <ta...@cservenak.net> 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 > > > > >> > > <configuration> 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 <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 à 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 > > > > >> > > > > > > > > > > > > > > > > > > -- > > > ------------------------ > > > Guillaume Nodet > > > > > > > > -- > ------------------------ > Guillaume Nodet >
