I agree with Tamás here, that's a really worse pattern, even more worse,
if the users configures the other mojo (deploy plugin in this case) and
it seems having no effect gives you the perfect WTF moments...
I also agree with the C&P argument, if I want to influence one aspect
its unlikley usefull to reimplment *everything*.
By the way the only thing needed to implement such thing would be that a
jar can promote itself as being "an spi" and therefore exporting its
packages to everyone using that jar, as such SPI implementations are
tighly coupled anyway it would even be fair to require a 1:1 match (such
SPI will likley seldom change if at all).
Currently Tycho does that by require the user to enable it as a build
extension and export the SPI jar, then there is a little helper class to
call the SPI in the realm of the plugin, so if this helper would be part
of maven core and the jar itself could "export" it would all be done.
Am 06.05.24 um 16:23 schrieb Tamás Cservenák:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
