Thanks Stuart.
The reproducibility PR you mention helps in having a deterministic ordering
inside the Named components file to buld exactly the same executable, but
it does not mean it is the right priority for component injection.
Do you know if it is possible to configure sisu to throw an exception if
trying to inject an ambiguous component? Otherwise, I guess we must
implement some sort of "ambiguity checker", either as an integration test
(don't know if it is possible) or either built-it into maven executable.
El sáb., 2 de nov. de 2019 a la(s) 20:54, Stuart McCulloch (
mccu...@gmail.com) escribió:
> Yes, when there are multiple non-default implementations with the same
> priority then it will pick the first in the list (where the "list" in
> question is actually a combination of plugins + extensions + core
> bindings for the given type)
>
> If a particular implementation should be treated as the default then it
> should either start with "Default" or be annotated with @Named("default") -
> the benefit of this approach is that it documents that this is the default
> implementation, to be favoured over the others. Alternatively if you want
> to have an ordering between implementations then you can use @Priority to
> assign specific priorities and favour one over the other.
>
> If you don't mark an implementation as default and don't define any
> priorities then the only current guarantees are that implementations in
> plugins and extensions will be favoured over implementations in core (to
> allow overriding). But there is an upcoming improvement to sort the list
> inside each module that would make this more deterministic from build to
> build, at least when ranking implementations inside a particular module:
> https://github.com/eclipse/sisu.inject/pull/5 - with that change then
> you'll get an extra guarantee that inside a module it will be ordered by
> package+name.
>
> PS. even with the old Plexus runtime annotations you could be at the whim
> of classpath ordering, similarly Plexus XML descriptors are influenced by
> classpath resource ordering - so ideally it's better to be explicit about
> ordering
>
> On Sat, 2 Nov 2019 at 23:07, Gabriel Belingueres <belingue...@gmail.com>
> wrote:
>
> > Hi:
> >
> > I just built maven core from source and found that it was using
> > StringSearchModelInterpolator instead of StringVisitorModelInterpolator,
> a
> > regression from the last 3.6.2 release.
> >
> > I found that in maven-model-builder/META-INF/sisu/javax.injected.Named
> > file, both interpolators are listed but in reverse order (comparing it
> with
> > the same file in 3.6.2), that is StringSearchModelInterpolator appear
> first
> > in the file and StringVisitorModelInterpolator second.
> >
> > (I believe the dependency injection picks up the first one it finds with
> > the right type.)
> >
> > Deleting the @Named annotation from StringSearchModelInterpolator solved
> > the issue, as this make the entry disappear from the javax.injected.Named
> > file. Then the dependency injection uses the
> > StringVisitorModelInterpolator.
> >
> > Can anyone confirm this issue?
> > And if so, how to best prevent in the future that this type of dependency
> > injection regressions from happening?
> >
> > Kind regards,
> > Gabriel
> >
>
