Re: JSR330 in extensions and plugins, Singleton or not Singleton

Guess we can do something like that or more js like http://tomee.apache.org/developer/classloading/index.html but specific to maven, mojo classloading is almost obvious but core and extension ones are not IMHO. Then we can just mention that for the IoC + it uses Guice with a custom registration imp

Re: JSR330 in extensions and plugins, Singleton or not Singleton

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_cl

Re: JSR330 in extensions and plugins, Singleton or not Singleton

@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/2ef97bf

Re: JSR330 in extensions and plugins, Singleton or not Singleton

> > 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.

Re: JSR330 in extensions and plugins, Singleton or not Singleton

@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 | Blog

Re: JSR330 in extensions and plugins, Singleton or not Singleton

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 ma

Re: JSR330 in extensions and plugins, Singleton or not Singleton

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 accr

Re: JSR330 in extensions and plugins, Singleton or not Singleton

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 idi

Re: JSR330 in extensions and plugins, Singleton or not Singleton

In CDI there is a definition which sounds like "an instance is a singleton in its context", context being the bean lookup definition. In maven it means calling Guice for current ClassRealm (the classloader of currently executed component - plugin for ex) so it matches. Long story short "singleton"

Re: JSR330 in extensions and plugins, Singleton or not Singleton

Just add few cents to Stuart superb answer: the singleton scope depends on the "realm" (no idea how to call it better) where it is singleton, as the "lifespan" of realm may not be same/aligned. Core and Core Extension lifespan vs Mojo/Plugin lifespan is clearly not the same... Also, take a peek at

Re: JSR330 in extensions and plugins, Singleton or not Singleton

Thank you Stuart for the detailed reply. On Fri, Feb 5, 2021 at 12:02 AM Stuart McCulloch wrote: > Here's a quick patch that does the split: > https://gist.github.com/mcculls/d22f01b0e380fdd9f9e2ac1e1bba7dd0 > > With these changes I get the following output: > > mvn validate > [INFO] extension g

Re: JSR330 in extensions and plugins, Singleton or not Singleton

Here's a quick patch that does the split: https://gist.github.com/mcculls/d22f01b0e380fdd9f9e2ac1e1bba7dd0 With these changes I get the following output: mvn validate [INFO] extension generated information: Build started at 1612479700634 [INFO] Scanning for projects... [INFO] [INFO] -

Re: JSR330 in extensions and plugins, Singleton or not Singleton

Yes it's down to classloading - the extension and plugin have different classloaders and the InfoHolder class loaded by the extension is different to the one loaded by the plugin. They may share the same name and have the same original bytecode, but they were defined by different classloaders. You

Re: JSR330 in extensions and plugins, Singleton or not Singleton

Hum some words have disappeared from my previous mail. The project URL is https://github.com/McFoggy/maven-jsr330-demo . And the corrected sentence is: You will see that the project is simple... Sorry for the double post. On Thu, Feb 4, 2021 at 9:2

JSR330 in extensions and plugins, Singleton or not Singleton

Hi all, As I was trying to cleanup & simplify my plugins by moving to JSR330, I came across a weird use case in which a `@Singleton` object exists multiple times (several instances) during the build: - it is first used by an extension, to store some value - then used in a mojo to retrieve and prin