<dependencies>
has another drawback that there is literally no way to further
customize/configure it so it is only suitable for trivial cases.
This would also not work when using more than one SPI.
One good example for OSGi use case (maybe others as well) is the maven
jar plugin, as there is no way to just add some new headers to the
manifest without either special configuration or hacks (e.g. extensions
or custom packing types), having a "plugin-spi" that gets wired only by
adding another Mojo allowing to compute additional headers would be the
natural solution.
Am 06.05.24 um 15:02 schrieb Tamás Cservenák:
Romain,
one more thing I missed to respond: you say
"plugin can define a specific SPI in its code and get it injected from a
plugin dep using its <configuration> block"
A) I hope you meant here "get it injected from a plugin dep using its
<dependencies> block" :)
Since as we know, doing trickeries like using <configuration> block to set
GAV-like things, that plugin resolves on its own is BAD THING to do: Maven
itself have no knowledge about such dependencies, and it totally breaks
reactor builds, where same thing is being built, and later used as "tricky
dependency". This pattern is bad as it is.
B) If defined as <dependencies>, then -- obviously -- the dependency
components will share the same plugin scope, so you are still in a very
"narrow" scope, as none of the mentioned plugins are _usually_ set up as
extensions (deploy, gpg). Moreover, remember the "early deploy at end"
implementation, that required m-deploy-p to be made into extension to make
the feature work... it just caused a ton of confusion to users.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
