OK, my bad, I thought we were talking about Maven's internals for itself. Classloader trees, hidden implementations, security policies for the JVM are stand out features that they nailed in 1995/6/7.
I once drew a pretty pic of Tomcat's classloader setup - https://paulhammant.com/images/tomcat_classloader.jpg - not from actually knowledge, but from "that's how I would do it" On Fri, Feb 5, 2021 at 1:32 PM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > @Paul: not really, none define any behavior (note that the class loader > tree implementation is a vendor choice, several certified EE servers do > handle singleton per tree or per loader of the tree and it is compliant). > Only @inject tests are > > https://github.com/eclipse-ee4j/injection-tck/blob/2ef97bfc0439f28730d4d1793f1ef9ff21309450/src/main/java/org/atinject/tck/auto/Convertible.java#L176 > which are mainly smoke tests to let vendors handle instances as they want > (proxy or not, eager vs lazy, scope/context definition etc). All that still > leads to the fact that the Maven IoC is not obvious on our doc, no? > > 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 à 13:55, Paul Hammant <p...@hammant.org.invalid> a > écrit : > > > > > > > JSR 330 has a TCK that defines a lot. A system that purports to > > facilitate > > > injection into contained components (plugins or lesser) doesn’t have to > > > implement all facets of that TCK but could do so out of the box by just > > > using (say) guice or dagger in a class loader tree implementation. > > >
