@Tamas, right but this page https://maven.apache.org/maven-jsr330.html does say the opposite for example, this is why I think we should create a ticket to revise the doc which is misleading as of today
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 5 févr. 2021 à 12:43, Tamás Cservenák <ta...@cservenak.net> a écrit : > When I read "jsr330" (in maven context), I always "replace it" with SISU in > my head, as Maven is SISU powered. > So there is nothing undefined for me, as SISU defines all the "blind spots" > IMO. > > Maven, while it may look so, will NOT work with any other JSR330 > implementation, just SISU. > Maven 3 was made to work with SISU (or SISU was made to replace Plexus, or > both :) > > My five cents. > > T > > On Fri, Feb 5, 2021 at 12:28 PM Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > > Issue with JSR330 is that it is a standard "nothing" since it does not > > define any behavior behind the annotations so it is pointless to have > this > > standard since all the behavior is vendor dependent and therefore we must > > fix that by a good doc. > > Wonder if we should define more explicitly and not accross 4-5 doc pages > > this. > > Anyone with more knowledge of the plexus migration knows if it is just > too > > much hidden and not well linked between these pages or if we have to > create > > a ticket to fix it - or even import some sisu doc/highlights? > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > > Le ven. 5 févr. 2021 à 12:11, Paul Hammant <p...@hammant.org.invalid> a > > écrit : > > > > > CDI came after JSR330 I think. I was on the JSR330 experts group. I > could > > > be wrong there. > > > > > > Back history of dependency injection - it was an antidote to classic > GoF > > > service-locator being used everywhere in Javaland. When we co-created > > > PicoContainer we were careful to avoid Singleton as a term or idiom for > > > good within the classbase and documentation. GoF singleton being a > > sibling > > > of service locator. Spring used the term in XML, then later as an > > > annotation (after Guice used Singleton as an annotation when Java5 > kicked > > > off). Then JSR330 gets to include it in the set of annotations. > > > > > > Anyway, I always told readers "single managed instance" was the thing > you > > > were trying to do. That could be one per JVM for a flat classloader > > design. > > > Or in a hierarchy of classloaders (Tomcat, Intellij, a stupid Jesktop > > > <http://jesktop.sourceforge.net/> thing I worked on) it would be one > per > > > meaningful separate part of a tree of classloaders in a JVM. > > > > > > These days, twice a year I get to give an opinion of a technology in a > > > language that purports to be DI, but is actually > > > Container.getInstance().getComponent(<some key>) by various > obfuscations > > > (service locator *not* DI at all). > > > > > > - Paul > > > > > >
