nice idea, but overriding by adding a new implementation in classpath is the
normal overriding way: not sure how "ambiguity checker" could make a difference
between such wanted override vs unwanted ambiguity
BTW, how did you see that StringVisitorModelInterpolator was not used but
StringSearchModelInterpolator instead, please?
Regards,
Hervé
Le dimanche 3 novembre 2019, 05:30:50 CET Gabriel Belingueres a écrit :
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
