Re: Override Maven core default bindings

2022-06-29 Thread Tamás Cservenák
Well, using the session for that would be much simpler... just my 5 cents So you could use participant only to implement this "protection", but keep using spy for the rest. T On Wed, Jun 29, 2022 at 1:24 PM François Guillot < francoisguillo...@gmail.com> wrote: > Hey, > > Thanks for all your

Re: Override Maven core default bindings

2022-06-29 Thread François Guillot
Hey, Thanks for all your suggestions. I don't like AbstractMavenLifecycleParticipant that much because it doesn't offer fine-grained callbacks. Only sessionStar/End and projectsRead. While EventSpy allows to hook into many more events fired by the EventCatapult. But this is just a detail. Thanks

Re: Override Maven core default bindings

2022-06-29 Thread Tamás Cservenák
And one more thing Migrate off from legacy Plexus XML src/main/resources/META-INF/plexus/components.xml and use JSR330 instead: - add javax.inject:javax.inject:1 as dependency - annotate your imple with @Singleton/@Named( "default" ) - use sisu-maven-plugin in the build to index annotated

Re: Override Maven core default bindings

2022-06-29 Thread Tamás Cservenák
Also, if you'd not use oldie EventSpy, but AbstractMavenLifecycleParticipant instead, you'd gain access to session, and would become even simpler: just stick something with specific (to your extension, like G:A) key and dummy value (Boolean,TRUE) into session. And then you know: if that key IS

Re: Override Maven core default bindings

2022-06-29 Thread Tamás Cservenák
Howdy, First of all, if you alter the maven classpath, there is not much Maven itself can do (as it happens before maven happens). How are conflicting classes handled depends on Java, not Maven. So, I'd really just neglect the use of `maven.ext.class.path` (or adding things to lib/ext). Using

Re: Override Maven core default bindings

2022-06-28 Thread François Guillot
Hi again I can't go into details because it's a proprietary extension, but we need to change the behaviour of - *DefaultMavenPluginManager*: we need to intercept calls to Mojo#execute so here we proxy the Mojo class that is created from the mojoInterface with some custom stuffs -

Re: Override Maven core default bindings

2022-06-28 Thread Tamás Cservenák
In other words, why do you need to override MavenPluginManager in several different ways? (or we just theoretize, about some possible future binary breakage?) T On Tue, Jun 28, 2022 at 1:12 PM Tamás Cservenák wrote: > Ok, > > best would be to create then a reproducer, but have to note: > while

Re: Override Maven core default bindings

2022-06-28 Thread Tamás Cservenák
Ok, best would be to create then a reproducer, but have to note: while Maven can "protect" (warn) about duplicate/wrong plugin declarations, as "lower" we go (and extensions, especially when you throw things into lib/ext) are earlier and earlier on the bootstrap of Maven, and it cannot do much

Re: Override Maven core default bindings

2022-06-28 Thread François Guillot
Hi Tamás, I have one extension (say 'MyExtension'), that declares a binding override for MavenPluginManager. MyExtension is not supposed to be applied several times per build, and I'm trying my best to keep only one of them 'active' if that happens. Given there are various ways to declare

Re: Override Maven core default bindings

2022-06-28 Thread Tamás Cservenák
Howdy, I am a bit uncertain if I correctly understand your problem: so you have several MavenPluginManager implementations in several extensions, and those extensions are not compatible with each other? Could we step back a little and could you explain what your extension is doing? Best if you