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 use
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 jus
Hi Tamas
If the proposed options dont implement a SPI the your solution neither
since there are equivalent, you are just more verbose and require more work
so still not following you.
Le lun. 6 mai 2024 à 18:45, Gary Gregory a écrit :
> Please don't use the version in the GAV as marketing, thi
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 expe
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_ existin
Le lun. 6 mai 2024 à 16:00, Tamás Cservenák 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 disagre
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).
This is not a future proof way to do it. To be precise, nx-staging-m-p
inject
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.
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-Buc
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
@rmannibu
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 a
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
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, T
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 wrote:
> Le lun. 6 mai 2024 à 14:38, Tamás C
Le lun. 6 mai 2024 à 14:38, Tamás Cservenák 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
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 block"
A) I hope you meant here "get it injected from a plugin dep using its
block" :)
Since as we know, doing trickeries like using block to set
GA
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 i
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.
That's all I wanted to prevent. Am fine with having
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
Le lun. 6 mai 2024 à 14:29, Tamás Cservenák 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
I also don't really see the value of having all SPI in a single repo.
It seems easier to have each SPI inside the repository of each maven plugin
instead.
Le lun. 6 mai 2024 à 14:25, Romain Manni-Bucau a
écrit :
> Hi Tamas,
>
> I kind of fail to see why org.apache.maven.maven-plugin-spi makes se
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.
Second, you mention a plugin dep, that is hence available in the same scope
as the plugin itself... which is obvious
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
block -
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:
* m
24 matches
Mail list logo
