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] ------------------------------------------------------------------------ [INFO] Building maven demo 0 [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-demo-mojo:0:info (demo) @ maven-demo --- [INFO] Information: Build started at 1612479700634 [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 0.108 s [INFO] Finished at: 2021-02-04T23:01:40Z [INFO] Final Memory: 9M/309M [INFO] ------------------------------------------------------------------------ On Thu, 4 Feb 2021 at 22:46, Stuart McCulloch <[hidden email]> wrote: > 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 can see this by adding a constructor to InfoHolder and printing out its > classloader (you can also print the class' hashcode to show it really is a > different class, just with the same name.) > > To share the extension class with the plugin you'll need to add an > extension descriptor to the jar: > > https://maven.apache.org/ref/3.6.0/maven-core/extension.html > > But you'll also need to solve a second issue which comes down to the fact > you're using the same jar as an extension and a plugin - the component > metadata is going to be registered in both places, which will still lead to > two separate copies (each component will be a singleton in its own 'realm' > governed by the component metadata.) > > I would recommend using two separate projects - one for the extension and > one for the plugin. The extension project will have the component and > the extension descriptor, while the plugin project will just have the mojo > and depend on the extension project. > > > On Thu, 4 Feb 2021 at 20:40, Matthieu Brouillard <[hidden email]> > wrote: > >> Hum some words have disappeared from my previous mail. >> The project URL is https://github.com/McFoggy/maven-jsr330-demo >> <https://github.com/McFoggy/maven-jsr330-demoYou>. >> 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:27 PM Matthieu Brouillard < >> [hidden email]> >> wrote: >> >> > 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 print the value >> > >> > Before opening an issue, I wanted to be sure that I did not make some >> > errors in the simplified project and that my expectations of how it >> should >> > work are OK. >> > >> > I pushed a simplified project with README here: >> > https://github.com/McFoggy/maven-jsr330-demoYou will that the project >> is >> > simple: >> > - the @Singleton information store >> > - the extension filling the store >> > - the mojo >> > >> > Thanks for any enlightenment. >> > >> > PS: can the issue come from different classloaders being probably used? >> > >> > Matthieu >> > >> > |
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" concept never exists, it is always a singleton under some restrictions ;). That said I wonder when an extension has mojo if the mojos shouldnt inherit from the extension classloader, it seems quite legitimate and I don't think forcing to do 2 modules is a solution (but it is clearly a workaround as of today). Wdyt? 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 à 11:47, Tamás Cservenák <[hidden email]> a écrit : > 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 maven classloading here > http://takari.io/book/91-maven-classloading.html > > > On Fri, Feb 5, 2021 at 10:40 AM Matthieu Brouillard < > [hidden email]> > wrote: > > > Thank you Stuart for the detailed reply. > > > > On Fri, Feb 5, 2021 at 12:02 AM Stuart McCulloch <[hidden email]> > > 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 generated information: Build started at 1612479700634 > > > [INFO] Scanning for projects... > > > [INFO] > > > [INFO] > > > > ------------------------------------------------------------------------ > > > [INFO] Building maven demo 0 > > > [INFO] > > > > ------------------------------------------------------------------------ > > > [INFO] > > > [INFO] --- maven-demo-mojo:0:info (demo) @ maven-demo --- > > > [INFO] Information: Build started at 1612479700634 > > > [INFO] > > > > ------------------------------------------------------------------------ > > > [INFO] BUILD SUCCESS > > > [INFO] > > > > ------------------------------------------------------------------------ > > > [INFO] Total time: 0.108 s > > > [INFO] Finished at: 2021-02-04T23:01:40Z > > > [INFO] Final Memory: 9M/309M > > > [INFO] > > > > ------------------------------------------------------------------------ > > > > > > > > > On Thu, 4 Feb 2021 at 22:46, Stuart McCulloch <[hidden email]> > wrote: > > > > > > > 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 can see this by adding a constructor to InfoHolder and printing > out > > > its > > > > classloader (you can also print the class' hashcode to show it really > > is > > > a > > > > different class, just with the same name.) > > > > > > > > To share the extension class with the plugin you'll need to add an > > > > extension descriptor to the jar: > > > > > > > > https://maven.apache.org/ref/3.6.0/maven-core/extension.html > > > > > > > > But you'll also need to solve a second issue which comes down to the > > fact > > > > you're using the same jar as an extension and a plugin - the > component > > > > metadata is going to be registered in both places, which will still > > lead > > > to > > > > two separate copies (each component will be a singleton in its own > > > 'realm' > > > > governed by the component metadata.) > > > > > > > > I would recommend using two separate projects - one for the extension > > and > > > > one for the plugin. The extension project will have the component and > > > > the extension descriptor, while the plugin project will just have the > > > mojo > > > > and depend on the extension project. > > > > > > > > > > > > On Thu, 4 Feb 2021 at 20:40, Matthieu Brouillard < > > [hidden email] > > > > > > > > wrote: > > > > > > > >> Hum some words have disappeared from my previous mail. > > > >> The project URL is https://github.com/McFoggy/maven-jsr330-demo > > > >> <https://github.com/McFoggy/maven-jsr330-demoYou>. > > > >> 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:27 PM Matthieu Brouillard < > > > >> [hidden email]> > > > >> wrote: > > > >> > > > >> > 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 print the value > > > >> > > > > >> > Before opening an issue, I wanted to be sure that I did not make > > some > > > >> > errors in the simplified project and that my expectations of how > it > > > >> should > > > >> > work are OK. > > > >> > > > > >> > I pushed a simplified project with README here: > > > >> > https://github.com/McFoggy/maven-jsr330-demoYou will that the > > project > > > >> is > > > >> > simple: > > > >> > - the @Singleton information store > > > >> > - the extension filling the store > > > >> > - the mojo > > > >> > > > > >> > Thanks for any enlightenment. > > > >> > > > > >> > PS: can the issue come from different classloaders being probably > > > used? > > > >> > > > > >> > Matthieu > > > >> > > > > >> > > > > > > > > > > |
@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 <[hidden email]> 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 <[hidden email]> > 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 <[hidden email]> 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 > > > > > > |
In reply to this post by Romain Manni-Bucau
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 impl. Le ven. 5 févr. 2021 à 17:13, Paul Hammant <[hidden email]> a écrit : > 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 <[hidden email]> > 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 <[hidden email]> 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. > > > > > > |
Free forum by Nabble | Edit this page |