You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Matthieu Brouillard <ma...@brouillard.fr> on 2021/02/04 20:27:21 UTC
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 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
Re: JSR330 in extensions and plugins, Singleton or not Singleton
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <pa...@hammant.org.invalid> 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 <rm...@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 <pa...@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.
> > >
> >
>
Re: JSR330 in extensions and plugins, Singleton or not Singleton
Posted by Paul Hammant <pa...@hammant.org.INVALID>.
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 <rm...@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 <pa...@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.
> >
>
Re: JSR330 in extensions and plugins, Singleton or not Singleton
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@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 <pa...@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.
>
Re: JSR330 in extensions and plugins, Singleton or not Singleton
Posted by Paul Hammant <pa...@hammant.org.INVALID>.
>
> 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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@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 <rm...@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 <pa...@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
> > >
> >
>
Re: JSR330 in extensions and plugins, Singleton or not Singleton
Posted by Tamás Cservenák <ta...@cservenak.net>.
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 <rm...@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 <pa...@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
> >
>
Re: JSR330 in extensions and plugins, Singleton or not Singleton
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <pa...@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
>
Re: JSR330 in extensions and plugins, Singleton or not Singleton
Posted by Paul Hammant <pa...@hammant.org.INVALID>.
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
Re: JSR330 in extensions and plugins, Singleton or not Singleton
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <ta...@cservenak.net> 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 <
> matthieu@brouillard.fr>
> wrote:
>
> > Thank you Stuart for the detailed reply.
> >
> > On Fri, Feb 5, 2021 at 12:02 AM Stuart McCulloch <mc...@gmail.com>
> > 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 <mc...@gmail.com>
> 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 <
> > matthieu@brouillard.fr
> > > >
> > > > 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 <
> > > >> matthieu@brouillard.fr>
> > > >> 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
> > > >> >
> > > >>
> > > >
> > >
> >
>
Re: JSR330 in extensions and plugins, Singleton or not Singleton
Posted by Tamás Cservenák <ta...@cservenak.net>.
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 <ma...@brouillard.fr>
wrote:
> Thank you Stuart for the detailed reply.
>
> On Fri, Feb 5, 2021 at 12:02 AM Stuart McCulloch <mc...@gmail.com>
> 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 <mc...@gmail.com> 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 <
> matthieu@brouillard.fr
> > >
> > > 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 <
> > >> matthieu@brouillard.fr>
> > >> 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
> > >> >
> > >>
> > >
> >
>
Re: JSR330 in extensions and plugins, Singleton or not Singleton
Posted by Matthieu Brouillard <ma...@brouillard.fr>.
Thank you Stuart for the detailed reply.
On Fri, Feb 5, 2021 at 12:02 AM Stuart McCulloch <mc...@gmail.com> 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 <mc...@gmail.com> 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 <matthieu@brouillard.fr
> >
> > 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 <
> >> matthieu@brouillard.fr>
> >> 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
> >> >
> >>
> >
>
Re: JSR330 in extensions and plugins, Singleton or not Singleton
Posted by Stuart McCulloch <mc...@gmail.com>.
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 <mc...@gmail.com> 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 <ma...@brouillard.fr>
> 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 <
>> matthieu@brouillard.fr>
>> 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
>> >
>>
>
Re: JSR330 in extensions and plugins, Singleton or not Singleton
Posted by Stuart McCulloch <mc...@gmail.com>.
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 <ma...@brouillard.fr>
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 <matthieu@brouillard.fr
> >
> 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
> >
>
Re: JSR330 in extensions and plugins, Singleton or not Singleton
Posted by Matthieu Brouillard <ma...@brouillard.fr>.
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 <ma...@brouillard.fr>
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
>