Re: Sisu Plexus release?

[Christoph Läubrich]

Hi Olivier,

I'm not 100% sure about the sisu[1] problem at Eclipse BUT usually there 
is no need for a vote or similar but from tiem to time there is a 
release or progress review. If I look here 
https://projects.eclipse.org/projects/technology.sisu/who you have 100% 
commits over the last three month, so it would make sense that @Konrad 
Windszus or @cstamas simply start a committer vote to make you a 
committer of the project, after that I would (if Stuart is non 
responsive anymore) start a Project Lead election for either any of you, 
at that point you then can do what ever is required (even though any 
committer can technically perform a release or ask for a release review 
some actions might require a Project Lead approval e.g. pushing to 
central), if you have any questions regarding Eclipse process you can 
ask the Eclipse EMO (e...@eclipse.org added as CC).


If you need any help I can offer to give some help from my experience in 
other Eclipse Projects, at a first glance looking at the release page[1] 
a release review seems overdue but I'm not an expert on this specific 
topic, it just wont hurt to schedule one just to be sure.


HTH
Christoph

[1] https://projects.eclipse.org/projects/technology.sisu
[2] https://projects.eclipse.org/projects/technology.sisu/governance

Am 07.05.24 um 23:23 schrieb Olivier Lamy:

Hi,
Sure but as a long-term developer, I cannot release this plexus part anymore.
It used to be very easy to release this major part of the system (but
for some reason this has been moved somewhere else. not something to
discuss again, of course)
I have been asking sisu dev mailing list for a release, but no answer yet.
I have been looking at this project mailing list archive.
There is an email about a possible process
(https://www.eclipse.org/lists/sisu-dev/msg00116.html), but as far as
I can see, this 0.9.0.M2 release has been done without any voting
process etc.
So releasing looks to be only a matter of having a few minutes to run
m-release-p and publish. (being contributor to another Eclipse
project, I cannot see anything with vote mandatory).

If it's easier we can certainly move this sisu plexus project back to
where it was few years ago under the groupId org.codehaus.plexus and
releasing will not be a problem for maven contributors.

regards
Olivier


On Mon, 6 May 2024 at 20:16, Tamás Cservenák  wrote:


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.

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 Mon, May 6, 2024 at 7:45 AM Olivier Lamy  wrote:


Is 3.9.7 really so urgent?
Maybe we can wait a couple of days.
I have been asking the sisu dev mailing list for a release.
This should not be too long.
I can see you are in the committers list
(https://projects.eclipse.org/projects/technology.sisu/who) with
Konrad so maybe you can help to expedite this?

regards
Olivier


On Sun, 5 May 2024 at 21:05, Tamás Cservenák  wrote:


Howdy,

Maven 3.9.7 was ready to be released 3 days ago and contains multiple

fixes

contributed by non committers.

MNG-8116 was added 2 days ago. I really see no reason to be blocked, to
"stop and wait" for a bugfix, as we can always spin 3.9.8.
Releases are cheap, and can be done whenever we (anyone of us) feels

right

to do so...

3.9.7 is not the "last Maven 3.9.x" or anything like that, to have a

"now

or never" situation. Just spin 3.9.8 whenever you think is ready.

My 5 cents
T

On Sun, May 5, 2024 at 2:14 AM Olivier Lamy  wrote:


Hi
Can we please integrate

https://issues.apache.org/jira/browse/MNG-8116

The fix is ready and really simple.

thanks
Olivier

On Wed, 24 Apr 2024 at 07:12, Tamás Cservenák 

wrote:


Howdy,

This is just a short newsflash about upcoming planned releases

related to

Maven.

Recently we got a huge spike in plugin releases, with various fixes

and

improvements. I will not enumerate all of them here, just use `mvn
versions:display-plugin-updates` to pick them up ;)
(and more plugins to come).

What I do want to share is about our upcoming Maven releases...

Maven 3.9.7 is nearing (read: coming soon), and will have an

important

Resolver update and other important fixes. Most importantly, the

file-locks

are getting nice improvement (feedback VERY welcome).

Maven 3.9.7 issues:




https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.7


Resolver 1.9.19 issues (mostly bug fixes):




https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19


At the same time, we plan to release Maven Daemon (m39) as well, to

have

it

aligned with Maven 

Re: [VOTE] Release Apache Maven Invoker version 3.3.0

[Jermaine Hua]

+1

Slawomir Jaranowski  于2024年5月8日周三 05:00写道：
>
> Hi,
>
> We solved 12 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12351567
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-invoker
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2113/
> https://repository.apache.org/content/repositories/maven-2113/org/apache/maven/shared/maven-invoker/3.3.0/maven-invoker-3.3.0-source-release.zip
>
> Source release checksum(s):
> maven-invoker-3.3.0-source-release.zip - SHA-512 :
> 746c8a1dd96c193690ae76f15198ab173767e1e9f5621697e6f6b4e207e698428c79f4c84f049ff216ca9e454ad3ffa2b80756a21c4d7cac577dc526083d86e3
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-invoker-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> --
> Sławomir Jaranowski

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Maven Doxia version 2.0.0-M11

[Jermaine Hua]

+1

Slawomir Jaranowski  于2024年5月8日周三 04:45写道：
>
> +1
>
> wt., 7 maj 2024 o 20:05 Michael Osipov  napisał(a):
>
> > Hi,
> >
> > we solved 1 issue:
> >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317230=12354655
> >
> > There are still a couple of issues left in JIRA:
> >
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20DOXIA%20AND%20resolution%20%3D%20Unresolved
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-2112/
> >
> > https://repository.apache.org/content/repositories/maven-2112/org/apache/maven/doxia/doxia/2.0.0-M11/doxia-2.0.0-M11-source-release.zip
> >
> > Source release checksum(s):
> > doxia-2.0.0-M11-source-release.zip
> > sha512:
> >
> > 809e92701cde9f378be0a84c1de357737e968a031acfdfb9bfe6ba8a9d579d563a9af2b3fdb546c0da4df3f35f95d3dada58d06b75367f2b22ea81b4025c2e96
> >
> > Staging site:
> > https://maven.apache.org/doxia/doxia-archives/doxia-LATEST/
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> Sławomir Jaranowski

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Sisu Plexus release?

[Olivier Lamy]

Hi,
Sure but as a long-term developer, I cannot release this plexus part anymore.
It used to be very easy to release this major part of the system (but
for some reason this has been moved somewhere else. not something to
discuss again, of course)
I have been asking sisu dev mailing list for a release, but no answer yet.
I have been looking at this project mailing list archive.
There is an email about a possible process
(https://www.eclipse.org/lists/sisu-dev/msg00116.html), but as far as
I can see, this 0.9.0.M2 release has been done without any voting
process etc.
So releasing looks to be only a matter of having a few minutes to run
m-release-p and publish. (being contributor to another Eclipse
project, I cannot see anything with vote mandatory).

If it's easier we can certainly move this sisu plexus project back to
where it was few years ago under the groupId org.codehaus.plexus and
releasing will not be a problem for maven contributors.

regards
Olivier


On Mon, 6 May 2024 at 20:16, Tamás Cservenák  wrote:
>
> 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.
> >
> > 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 Mon, May 6, 2024 at 7:45 AM Olivier Lamy  wrote:
> >
> >> Is 3.9.7 really so urgent?
> >> Maybe we can wait a couple of days.
> >> I have been asking the sisu dev mailing list for a release.
> >> This should not be too long.
> >> I can see you are in the committers list
> >> (https://projects.eclipse.org/projects/technology.sisu/who) with
> >> Konrad so maybe you can help to expedite this?
> >>
> >> regards
> >> Olivier
> >>
> >>
> >> On Sun, 5 May 2024 at 21:05, Tamás Cservenák  wrote:
> >> >
> >> > Howdy,
> >> >
> >> > Maven 3.9.7 was ready to be released 3 days ago and contains multiple
> >> fixes
> >> > contributed by non committers.
> >> >
> >> > MNG-8116 was added 2 days ago. I really see no reason to be blocked, to
> >> > "stop and wait" for a bugfix, as we can always spin 3.9.8.
> >> > Releases are cheap, and can be done whenever we (anyone of us) feels
> >> right
> >> > to do so...
> >> >
> >> > 3.9.7 is not the "last Maven 3.9.x" or anything like that, to have a
> >> "now
> >> > or never" situation. Just spin 3.9.8 whenever you think is ready.
> >> >
> >> > My 5 cents
> >> > T
> >> >
> >> > On Sun, May 5, 2024 at 2:14 AM Olivier Lamy  wrote:
> >> >
> >> > > Hi
> >> > > Can we please integrate
> >> https://issues.apache.org/jira/browse/MNG-8116
> >> > > The fix is ready and really simple.
> >> > >
> >> > > thanks
> >> > > Olivier
> >> > >
> >> > > On Wed, 24 Apr 2024 at 07:12, Tamás Cservenák 
> >> wrote:
> >> > > >
> >> > > > Howdy,
> >> > > >
> >> > > > This is just a short newsflash about upcoming planned releases
> >> related to
> >> > > > Maven.
> >> > > >
> >> > > > Recently we got a huge spike in plugin releases, with various fixes
> >> and
> >> > > > improvements. I will not enumerate all of them here, just use `mvn
> >> > > > versions:display-plugin-updates` to pick them up ;)
> >> > > > (and more plugins to come).
> >> > > >
> >> > > > What I do want to share is about our upcoming Maven releases...
> >> > > >
> >> > > > Maven 3.9.7 is nearing (read: coming soon), and will have an
> >> important
> >> > > > Resolver update and other important fixes. Most importantly, the
> >> > > file-locks
> >> > > > are getting nice improvement (feedback VERY welcome).
> >> > > >
> >> > > > Maven 3.9.7 issues:
> >> > > >
> >> > >
> >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.7
> >> > > >
> >> > > > Resolver 1.9.19 issues (mostly bug fixes):
> >> > > >
> >> > >
> >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19
> >> > > >
> >> > > > At the same time, we plan to release Maven Daemon (m39) as well, to
> >> have
> >> > > it
> >> > > > aligned with Maven 3,9,7: with many bug fixes and
> >> improvements/alignments
> >> > > > to "how Maven 3 behave". Our goal is to make the two (mvn and mvnd)
> >> > > > interchangeable on workstations.
> >> > > >
> >> > > > Next, Maven 4 is turning beta, so the next release will be beta1!
> >> And
> >> > > > again, same thing for Maven Damon (m40), we will have a release
> >> that will
> >> > > > include Maven 4 beta-1.
> >> > > >
> >> > > > Maven 4 beta-1
> >> > > >
> >> > >
> >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-beta-1
> >> > > >
> >> > > > Resolver 2.0.0 (currently alpha-11, will become beta after Maven4
> >> beta-1
> >> > > > release):
> >> > > 

[VOTE] Release Apache Maven Invoker version 3.3.0

[Slawomir Jaranowski]

Hi,

We solved 12 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12351567

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-invoker

Staging repo:
https://repository.apache.org/content/repositories/maven-2113/
https://repository.apache.org/content/repositories/maven-2113/org/apache/maven/shared/maven-invoker/3.3.0/maven-invoker-3.3.0-source-release.zip

Source release checksum(s):
maven-invoker-3.3.0-source-release.zip - SHA-512 :
746c8a1dd96c193690ae76f15198ab173767e1e9f5621697e6f6b4e207e698428c79f4c84f049ff216ca9e454ad3ffa2b80756a21c4d7cac577dc526083d86e3

Staging site:
https://maven.apache.org/shared-archives/maven-invoker-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1

-- 
Sławomir Jaranowski

Re: [VOTE] Release Maven Doxia version 2.0.0-M11

[Slawomir Jaranowski]

+1

wt., 7 maj 2024 o 20:05 Michael Osipov  napisał(a):

> Hi,
>
> we solved 1 issue:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317230=12354655
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20DOXIA%20AND%20resolution%20%3D%20Unresolved
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2112/
>
> https://repository.apache.org/content/repositories/maven-2112/org/apache/maven/doxia/doxia/2.0.0-M11/doxia-2.0.0-M11-source-release.zip
>
> Source release checksum(s):
> doxia-2.0.0-M11-source-release.zip
> sha512:
>
> 809e92701cde9f378be0a84c1de357737e968a031acfdfb9bfe6ba8a9d579d563a9af2b3fdb546c0da4df3f35f95d3dada58d06b75367f2b22ea81b4025c2e96
>
> Staging site:
> https://maven.apache.org/doxia/doxia-archives/doxia-LATEST/
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: [VOTE] Release Maven Doxia version 2.0.0-M11

[Sylwester Lachiewicz]

+1

wt., 7 maj 2024, 20:05 użytkownik Michael Osipov 
napisał:

> Hi,
>
> we solved 1 issue:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317230=12354655
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20DOXIA%20AND%20resolution%20%3D%20Unresolved
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2112/
>
> https://repository.apache.org/content/repositories/maven-2112/org/apache/maven/doxia/doxia/2.0.0-M11/doxia-2.0.0-M11-source-release.zip
>
> Source release checksum(s):
> doxia-2.0.0-M11-source-release.zip
> sha512:
>
> 809e92701cde9f378be0a84c1de357737e968a031acfdfb9bfe6ba8a9d579d563a9af2b3fdb546c0da4df3f35f95d3dada58d06b75367f2b22ea81b4025c2e96
>
> Staging site:
> https://maven.apache.org/doxia/doxia-archives/doxia-LATEST/
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

[VOTE] Release Maven Doxia version 2.0.0-M11

[Michael Osipov]

Hi,

we solved 1 issue:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317230=12354655

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20DOXIA%20AND%20resolution%20%3D%20Unresolved

Staging repo:
https://repository.apache.org/content/repositories/maven-2112/
https://repository.apache.org/content/repositories/maven-2112/org/apache/maven/doxia/doxia/2.0.0-M11/doxia-2.0.0-M11-source-release.zip

Source release checksum(s):
doxia-2.0.0-M11-source-release.zip
sha512: 
809e92701cde9f378be0a84c1de357737e968a031acfdfb9bfe6ba8a9d579d563a9af2b3fdb546c0da4df3f35f95d3dada58d06b75367f2b22ea81b4025c2e96


Staging site:
https://maven.apache.org/doxia/doxia-archives/doxia-LATEST/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Maven Plugin SPI

[Christoph Läubrich]

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 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 
wrote:


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 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)



Rightwhich 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 





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  |  Blog
 | Old Blog
 | Github <
https://github.com/rmannibucau> |
LinkedIn  | Book
<




https://www.packtpub.com/application-development/java-ee-8-high-performance





Le lun. 6 mai 2024 à 15:48, Tamás Cservenák  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  |  Blog
 | Old Blog
 | Github <
https://github.com/rmannibucau> |
LinkedIn 

Re: [DISCUSS] Maven Plugin SPI

[Christoph Läubrich]

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  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
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 , 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 
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
 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  |  Blog
 | Old Blog
 | Github <
https://github.com/rmannibucau> |
LinkedIn  | Book
<
https://www.packtpub.com/application-development/java-ee-8-high-performance





Le lun. 6 mai 2024 à 14:08, Tamás Cservenák  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