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
Looks good to me. ;)
Thank you by advance.
Kind regards,
Kevin
Le ven. 3 mai 2024, 05:40, Olivier Lamy a écrit :
> Hi,
> A couple of new features and fixes have been contributed.
> I would like to release this maybe next week.
> Probably randomly between Monday and Sunday (yeah, that's a enoug
Well not sure what you didn't get from my mails but
1. I agree current solution does not need anything new if it was ambiguous
2. the mail you reference was for jreleaser outside maven so out of topic
there IMHO
If MDK does not need an external SPI I agree with you there is no new
concept nor nee
>
>
> Well, for *existing* core component I don't see an issue to add a toggle to
> say "deploy at end".
> What can be an issue there is only to make it global for the session and
> not per artifact + how to define "end" - agree onSessionClose can be too
> late but sure we can find a good "phase" (
Well, for *existing* core component I don't see an issue to add a toggle to
say "deploy at end".
What can be an issue there is only to make it global for the session and
not per artifact + how to define "end" - agree onSessionClose can be too
late but sure we can find a good "phase" (plain english
And few more things:
- my intent is to target BOTH, Maven3 and Maven4, as when Sonatype
deprecates OSS/S01 in favor of Central Portal, Maven3 (and currently also
Maven4) users are doomed to "roll their own" solutions for Central
publishing. While Sonatype Nx2 (running on Sonatype OSS/S01 and ASF re
Hi,
+1 from me.
Kind regards
Karl Heinz Marbaise
PS.: Version Number related to Maven 4 API (was already mentioned).
On 05.05.24 21:29, Michael Osipov wrote:
Hi,
we solved 4 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317923&version=12354123
There are still a
>
>
> If you don't need to create a new module nor any new interface in maven
> core or a shared module I'm all for the change, otherwise it is a new
> shared thing whatever you present it.
>
So, if we don't change anything, you accept the "change"? :)
In short: MDK is just a "tech demo", but the
Le lun. 6 mai 2024 à 19:40, Tamás Cservenák a écrit :
> Howdy,
>
> inline.
>
>
> Exactly...this is what will always happen with plugins and extensions.
> > Indeed you can add a phase after plugins then you moved the issue to one
> > more step but the issue is still *exactly* the same but in a new
Howdy,
inline.
Exactly...this is what will always happen with plugins and extensions.
> Indeed you can add a phase after plugins then you moved the issue to one
> more step but the issue is still *exactly* the same but in a new concept
> and layer, so literally no gain there.
>
This is not a ne
Le lun. 6 mai 2024 à 18:55, Tamás Cservenák a écrit :
> Romain,
>
> I have more and more the feeling that you are not reading what has been
> written down, at least not carefully enough.
>
> Otherwise, you';d know that is it NOT "already doable", as explained in MDK
> doco (but also in previous t
Romain,
I have more and more the feeling that you are not reading what has been
written down, at least not carefully enough.
Otherwise, you';d know that is it NOT "already doable", as explained in MDK
doco (but also in previous thread):
Just one example: the current "deploy at end" feature of m-d
Hi Tamas
So it is just a spi consommable from a plugin using an extension to share a
state accross mojo execution...so nothing we already do.
My understanding of your request is to bring to maven 4 api this concept
for common needs (delayed tasks I'd say more than anything specific to
deployment)
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
Howdy,
Please take a peek at (and maybe try out) latest Maveniverse project, MDK:
https://github.com/maveniverse/mdk
This is like "proof of concept" or "demo" of what the Plugin SPI pattern
would be able to do.
The idea is to broaden the support, and provide services even like
"overlaid staging
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
Romain,
You can look at this change (which I did, for plugin testing) just like
resolver-1.9.x branch: a "stable" release of testing for 3.x plugins is
very desperately needed.
Same thing for maven-plugin-plugin. So yes, this is kinda the b) option: a
Maven4 plugin cannot be built (m-p-p or tested
Hi Tamas,
If the impact is to prevent to build a maven 3 (original setup version or
CI version for ex) with maven 4 (local version for ex) then I think it
violates the contract we had for maven 4 and I'd really like it to not
happen.
If it is the opposite (a maven 4 based/native project can't be r
Btw, I feel really strange to have to explain to a long term maven
contributor, that he can do maven release whenever he feels so
T
On Mon, May 6, 2024 at 11:59 AM Tamás Cservenák wrote:
> Howdy,
>
> I think you reversed the question... 3.9.7 was done and ready to go until
> you stepped in.
if you think it's urgent do whatever you want..
On Mon, 6 May 2024 at 20:01, Tamás Cservenák wrote:
>
> Howdy,
>
> I think you reversed the question... 3.9.7 was done and ready to go until
> you stepped in.
>
> IMHO the real question is:
> Is your issue (using overloaded methods in mojo confi
Howdy,
my pain point was plugin-testing-harness 3.3.0 that is really ancient,
while master of it was mixing maven3 and maven4 support... so I went to
split things.
IMO we need to split (like maven-3.x and master branch) for maven 3 and
maven 4 support, as there is really no need to support "both"
Howdy,
I think you reversed the question... 3.9.7 was done and ready to go until
you stepped in.
IMHO the real question is:
Is your issue (using overloaded methods in mojo config) really so urgent to
halt 3.9.7 release?
What is the problem with doing 3.9.8 maybe even two weeks later?
Thanks
T
On 2024/05/06 06:57:00 Hervé Boutemy wrote:
> +1
>
> Reproducible Build ok: reference build done with JDK 8 on Windows and umask =
> 022 (parent POM not upgraded, which should remove the umask requirement)
Parent upgrade is planned for the next release train.
---
On 2024/05/06 07:44:43 Konrad Windszus wrote:
> Hi,
> There was a longer discussion in
> https://www.mail-archive.com/dev@maven.apache.org/msg132078.html (for some
> reason cannot find the thread in
> https://lists.apache.org/list.html?dev@maven.apache.org) and we kind of came
> to an agreement
Hi,
There was a longer discussion in
https://www.mail-archive.com/dev@maven.apache.org/msg132078.html (for some
reason cannot find the thread in
https://lists.apache.org/list.html?dev@maven.apache.org) and we kind of came to
an agreement to reserve plugin major version 4 for plugins leveraging
46 matches
Mail list logo
