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 <ta...@cservenak.net> wrote:
> 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 ?
>> > >
>> >
>>
>
