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 there...
Hence, while Maven tries its best to protect you (users) from mistakes, it
cannot always do it, especially when things are just added to classpath....
Also, non-backward compatible with your implementation of the Maven
component (interface) of MavenPluginManager?
Again, I'd really like to see what happens here, what the extension intent
is, not only "reproducer" for "multiple extensions override the same
component".
Tamas
On Tue, Jun 28, 2022 at 12:32 PM François Guillot <
francoisguillo...@gmail.com> wrote:
> 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 extensions ('.mvn/extensions.xml',
> 'lib/ext' in Maven installation, '-Dmaven.ext.class.path'), the order of
> applications of extensions, the fact they are not loaded in the same
> classloader makes it a bit hard to do.
> But I'm managing that.
> The only thing I'm not managing 'in code' is controlling which extension
> wins and overrides the Maven core bindings.
>
> I'm thinking ahead if at some point I'm making a non backward compatible
> change (wrt to my extension code) in my implementation of
> MavenPluginManager, than I can be in trouble, where the 'chosen'
> MavenPluginManager implementation will not be compatible with the 'chosen'
> MyExtension.
>
> I can't share the code of my extension, but I could produce a little
> reproducer with a noop extension to show you what I mean.
>
> Le mar. 28 juin 2022 à 11:45, Tamás Cservenák <ta...@cservenak.net> a
> écrit :
>
> > 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 could show us some sources?
> >
> > HTH
> > Tamas
> >
> >
> >
> > On Tue, Jun 28, 2022 at 10:18 AM François Guillot <
> > francoisguillo...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I need to override some default Maven bindings in my custom extension,
> > for
> > > instance "org.apache.maven.plugin.MavenPluginManager"
> > >
> > > I'm doing this by providing a "META-INF/plexus/components.xml" in my
> > > extension's jar with
> > > <<
> > >
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <component-set>
> > > <components>
> > > <component>
> > > <role>org.apache.maven.plugin.MavenPluginManager</role>
> > > <implementation>com.acme.MyMavenPluginManager</implementation>
> > >
> > > </component>
> > > </components>
> > > </component-set>
> > >
> > > >>
> > >
> > > This works fine, but this has limitations.
> > > If for some reasons, my extension is applied twice or more to the
> build,
> > > then all of these applications will override the Maven core binding. My
> > > finding is that the last application wins.
> > > This can be problematic if the user is applying several _versions_ of
> my
> > > extension (probably unknowingly), because the overridden
> > MavenPluginManager
> > > might be coming from a version of my extension that is not compatible
> > with
> > > the code in the other one.
> > >
> > > Is there a more programmatic way to override Maven core bindings, that
> > > would allow me to decide whether a given extension should perform the
> > > override or not ?
> > >
> >
>
