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 <gno...@apache.org> 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 <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 >
