Scratch that - the AetherModule and DefaultServiceLocator are only used by
clients that don't use dependency injection, they're not used by Maven
itself.

The log snippet you posted above shows both SyncContextFactory components
are being bound in the same realm - they are therefore given the exact same
priority, both being "default", which means the one with the earlier
alphabetical name wins. This is DefaultSyncContextFactory, as shown by its
order in the logs.

Note if the replacement component was bound in a plugin realm then it would
automatically win because the baseline priority is bumped for each plugin
realm added to the system. This is to support Maven's standard behaviour of
always allowing a plugin to override previously bound components. A
component's priority is based on the baseline priority of its realm, with
default components given a boost compared to non-default components. In
other words default components always have a higher priority than
non-default components regardless of the realm/plugin, while components
bound in later plugins have slightly higher priorities than the equivalent
component bound in earlier plugins.

Because the replacement component is bound in the same realm as the
original (since the extension is being pulled into the core realm) then it
has the same baseline priority. So to make sure it appears first you'll
need to explicitly give it a higher priority. You can do this by adding:

    @javax.annotation.Priority(Integer.MAX_VALUE)

to RedissonSyncContextFactory - this will give that component the highest
priority, so it will always appear before any other implementation of that
interface.

On Wed, 12 Aug 2020 at 10:17, Stuart McCulloch <mccu...@gmail.com> wrote:

> The issue is indeed with AetherModule which is installed by Maven
> via MavenAetherModule
>
> This module adds concrete bindings for various Aether components which
> cannot be overridden in plugins/extensions.
>
> These bindings will need to be changed to support overriding, I'll create
> a patch to show how this could be done.
>
> On Tue, 11 Aug 2020 at 12:07, Michael Osipov <micha...@apache.org> wrote:
>
>> Am 2020-08-11 um 11:48 schrieb Stuart McCulloch:
>> > JSR330 annotation scanning is enabled for all realms including
>> > extensions, so it should be picked up.
>> >
>> > Does the replacement implementation have the same "hint" or name?
>> > ie. @Named("default")
>> >
>> > You can turn on detailed container logging with -Dsisu.debug which will
>> log
>> > all bindings discovered in each realm/extension and any potential
>> issues.
>>
>> Hi Stuart,
>>
>> I have followed your advice and added explicit names: "default" for both:
>>
>> > @Named( "default" )
>> > @Singleton
>> > public class DefaultSyncContextFactory
>> >     implements SyncContextFactory
>>
>> and
>>
>> > @Named( "default" )
>> > @Singleton
>> > public class RedissonSyncContextFactory
>> >     implements SyncContextFactory
>>
>> I can see this:
>> > 77. LinkedKeyBinding{key=Key[type=java.lang.Object, annotation=*],
>> source=ClassRealm[plexus.core, parent: null], scope=Scopes.NO_SCOPE,
>> target=Key[type=org.eclipse.aether.internal.impl.DefaultSyncContextFactory,
>> annotation=[none]]}
>> > 78. LinkedKeyBinding{key=Key[type=java.lang.Object, annotation=*],
>> source=ClassRealm[plexus.core, parent: null], scope=Scopes.NO_SCOPE,
>> target=Key[type=org.eclipse.aether.synccontext.RedissonSyncContextFactory,
>> annotation=[none]]}
>> > 249.
>> ProviderInstanceBinding{key=Key[type=org.eclipse.aether.impl.SyncContextFactory,
>> annotation=[none]], source=org.eclipse.sisu.wire.LocatorWiring,
>> scope=Scopes.NO_SCOPE,
>> provider=org.eclipse.sisu.wire.BeanProviders$7@6cce16f4}
>> > 334.
>> ConstructorBinding{key=Key[type=org.eclipse.aether.internal.impl.DefaultSyncContextFactory,
>> annotation=[none]], source=ClassRealm[plexus.core, parent: null],
>> scope=Scopes.SINGLETON}
>> > 335.
>> ConstructorBinding{key=Key[type=org.eclipse.aether.synccontext.RedissonSyncContextFactory,
>> annotation=[none]], source=ClassRealm[plexus.core, parent: null],
>> scope=Scopes.SINGLETON}
>>
>> I am afraid that the AetherModule as well as DefaultServiceLocator
>> basically break the bean names, thus making it unusable. The extension
>> is defitively not picked up because I don't see log statements from it.
>>
>> Tried also:
>> > bind( SyncContextFactory.class ).annotatedWith( Names.named( "default"
>> ) ) //
>> >         .to( DefaultSyncContextFactory.class ).in( Singleton.class );
>>
>> Even removing did not work.
>>
>> Changed order in m2.conf, no avail.
>>
>> Anything else I could try?
>>
>> Michael
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>

Reply via email to