Yep, which means that the executioncontext of the plugin should also switch to the right tccl probably as you mentionned.
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 mer. 23 nov. 2022 à 14:25, Patrick Plenefisch <[email protected]> a écrit : > Right, so there are 3 important realms. realm > coreExtension>io.takari.polyglot:polyglot-ruby:0.4.7 is what I assume is > loaded from .mvn/extensions.xml, and is the parent classloader of Ruby. > realm extension>org.apache.felix:maven-bundle-plugin:4.2.1 is weird in > that it can resolve the class, but doesn't have an instance of the class > when that class is passed to container.lookup(). it isn't used anywhere > relevant. Finally, realm > plugin>io.takari.polyglot:polyglot-maven-plugin:0.4.7 can resolve the > class, and container.lookup of the resolved class returns an instance. > However this isn't accessible from Ruby, though it is the TCCL. > > I believe the loading process is as follows: > > 1. .mvn/extensions.xml is loaded, which loads polyglot, which in turn > starts the JRuby engine > 2. The JRuby engine executes pom.rb, defining stuff, including the > "execute do ... end" tasks > 3. The definitions are passed to maven, which loads the plugin polyglot > class realm, and then somehow invokes the first, already existing JRuby > engine from the extensions > 4. Classloader confusion ensues > > > > On Wed, Nov 23, 2022 at 8:15 AM Romain Manni-Bucau <[email protected]> > wrote: > > > The TCCL of the plugin should be the plugin classloader, in all other > cases > > it will likely just fail without any hack (like stealing the right > > classloader). > > I'm not sure I fully get your table - or if gmail misformatted it - but > if > > it is a plain plugin declaration this should be ok, if declared as an > > extension it can be another thing. > > > > 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 mer. 23 nov. 2022 à 13:55, Patrick Plenefisch <[email protected]> a > > écrit : > > > > > Both that and trying to simply get the Class<T>. After some > > investigation, > > > I made a table with the below code: > > > > > > > > > matchR,matchT,loadclass,.lookup(), realm > > > ...... ...... ..!Ex! , ........ for realm plexus.core > > > PARENT ...... ..!Ex! , ........ for realm > > > coreExtension>io.takari.polyglot:polyglot-ruby:0.4.7 > > > ...... ...... ..!Ex! , ........ for realm maven.ext > > > ...... ...... ..!Ex! , ........ for realm maven.api > > > ...... ...... ..!Ex! , ........ for realm > > > extension>org.torquebox.mojo:mavengem-wagon:1.0.3 > > > ...... ...... ..!Ex! , ........ for realm > > > project>org.jruby:jruby-stdlib:9.4.0.0-SNAPSHOT > > > ...... ...... Loaded, null.... for realm > > > extension>org.apache.felix:maven-bundle-plugin:4.2.1 > > > ...... ...... ..!Ex! , ........ for realm > > > project>org.jruby:jruby-complete:9.4.0.0-SNAPSHOT > > > ...... ...... ..!Ex! , ........ for realm > > > plugin>org.apache.maven.plugins:maven-enforcer-plugin:1.0 > > > ...... THREAD Loaded, Instance for realm > > > plugin>io.takari.polyglot:polyglot-maven-plugin:0.4.7 > > > > > > > > > def test_realms(ctx) > > > ccl = java.lang.Thread.currentThread().getContextClassLoader() > > > parent = JRuby.runtime.jruby_class_loader.parent > > > ctx.session.container.class_world.realms.each do |realm| > > > results = [] > > > print(if realm == parent then "PARENT " else "...... " end) > > > print(if realm == ccl then "THREAD " else "...... " end) > > > begin > > > clz = > > > > > > > > > realm.load_class("org.apache.maven.shared.dependency.graph.DependencyGraphBuilder") > > > print " Loaded, " > > > ctx.session.container.lookup(clz) > > > print " Instance " > > > rescue java.lang.ClassNotFoundException =>e > > > print " ..!Ex! , ........ " > > > rescue > > > > > > > > > Java::OrgCodehausPlexusComponentRepositoryException::ComponentLookupException > > > =>e > > > print " null.... " > > > end > > > puts " for realm #{realm.id}" > > > end > > > end > > > > > > The interesting thing I notice here is that the parent classloader of > the > > > ruby plugin is the original core extension. Would this be a bug for the > > > polyglot plugin itself? ie. should it transition the parent classloader > > to > > > the thread class loader? > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Nov 23, 2022 at 2:58 AM Romain Manni-Bucau < > > [email protected]> > > > wrote: > > > > > > > Do you mean the container.lookup fails? > > > > Normally, with the metadata in the jar, the default impl ( > > > > > > > > > > > > > > https://github.com/apache/maven-dependency-tree/blob/master/src/main/java/org/apache/maven/shared/dependency/graph/internal/DefaultDependencyGraphBuilder.java > > > > ) > > > > should be returned. > > > > > > > > If not maybe ensure the ruby plugin does not ignore the plugin > > > dependencies > > > > with a custom classloader. > > > > > > > > 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 mer. 23 nov. 2022 à 02:10, Patrick Plenefisch < > [email protected]> > > a > > > > écrit : > > > > > > > > > Getting the DependencyGraphBuilder to be on the classpath is > turning > > > out > > > > > trickier than anticipated. I added both normal dependencies, and > as a > > > > > dependency inside the plugin, but neither seems to be resolved. Do > I > > > have > > > > > to manually resolve this dependency inside the mojo? > > > > > > > > > > <plugin> > > > > > ... > > > > > <dependencies> > > > > > <dependency> > > > > > <groupId>org.apache.maven.shared</groupId> > > > > > <artifactId>maven-dependency-tree</artifactId> > > > > > <version>3.2.1</version> > > > > > </dependency> > > > > > </dependencies> > > > > > </plugin> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Nov 22, 2022 at 10:49 AM Patrick Plenefisch < > > > [email protected] > > > > > > > > > > wrote: > > > > > > > > > > > irb(#<Maven::Polyglot::Parser:0x62c6db99>):002:0> > > > ctx.session.container > > > > > > => #<Java::OrgCodehausPlexus::DefaultPlexusContainer:0x3efe7086> > > > > > > > > > > > > Well, would you look at that! Literal hours of staring at the > > javadoc > > > > > over > > > > > > multiple days and yet somehow I missed that. Though to be fair I > > did > > > > type > > > > > > .context and search the javadoc and code for "context" before I > > > > realized > > > > > > you said "container". Though it is deprecated? Good enough for me > > > > though. > > > > > > Thanks! > > > > > > > > > > > > Thanks, > > > > > > Patrick > > > > > > > > > > > > On Tue, Nov 22, 2022 at 10:33 AM Romain Manni-Bucau < > > > > > [email protected]> > > > > > > wrote: > > > > > > > > > > > >> *ctx.session.container* ? > > > > > >> > > > > > >> > > > > > >> Le mar. 22 nov. 2022 à 16:23, Patrick Plenefisch < > > > [email protected] > > > > > > > > > > a > > > > > >> écrit : > > > > > >> > > > > > >> > No, how would I do that with the released version of Mojo > > today? I > > > > > know > > > > > >> the > > > > > >> > standard version of injecting for java uses a field and an > > > > annotation, > > > > > >> but > > > > > >> > I'm not writing java, and I don't know how to adapt that to my > > > > > polyglot > > > > > >> > pom-inline code: > > > > > >> > https://github.com/jruby/jruby/blob/master/lib/pom.rb#L209 > > > > > >> > > > > > > >> > Patrick > > > > > >> > > > > > > >> > On Tue, Nov 22, 2022 at 10:13 AM Romain Manni-Bucau < > > > > > >> [email protected] > > > > > >> > > > > > > > >> > wrote: > > > > > >> > > > > > > >> > > Hi Patrick, > > > > > >> > > > > > > > >> > > Did you try injecting PlexusContainer? > > > > > >> > > It is not the most sexy and modern way to do it but it fits > > > quite > > > > > well > > > > > >> > the > > > > > >> > > scripting language since the container enables to lookup > > > anything, > > > > > it > > > > > >> is > > > > > >> > > just a matter of injecting it in the mojo then forwarding it > > to > > > > the > > > > > >> > script. > > > > > >> > > > > > > > >> > > Side note: I assume a more modern solution is to inject the > > sisu > > > > > >> > > BeanLocator but its package is not exposed to mojo > > > (intentionally) > > > > > so > > > > > >> it > > > > > >> > > can be trickier to play with ClassRealms to get it. > > > > > >> > > > > > > > >> > > I would also avoid the generation trick since it will also > > have > > > > > >> pitfalls > > > > > >> > > (leaks, manual registration, cache) and is not simpler. > > > > > >> > > > > > > > >> > > Hope it helps a bit. > > > > > >> > > > > > > > >> > > 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 mar. 22 nov. 2022 à 16:04, Patrick Plenefisch < > > > > > [email protected]> > > > > > >> a > > > > > >> > > écrit : > > > > > >> > > > > > > > >> > > > Hi, > > > > > >> > > > How can I query a specific dependency's *resolved* > > transitive > > > > > >> > > dependencies > > > > > >> > > > inside a class executed by a mojo? I have access to > session > > > and > > > > > >> > project, > > > > > >> > > > and that's it. > > > > > >> > > > I looked at DependencyGraphBuilder and the underlying > > > > > >> > > > ProjectDependenciesResolver, but those seem to be > injected. > > > > While > > > > > I > > > > > >> can > > > > > >> > > > generate a class at runtime, I don't see how to access the > > > > > injector > > > > > >> > even > > > > > >> > > if > > > > > >> > > > I have a class > > > > > >> > > > > > > > > >> > > > The environment I'm running inside is JRuby inside > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > https://github.com/takari/polyglot-maven/blob/master/polyglot-maven-plugin/src/main/java/org/sonatype/maven/polyglot/plugin/ExecuteMojo.java > > > > > >> > > > which is why I can't just use an @Inject annotation. But, > > > being > > > > > >> JRuby, > > > > > >> > I > > > > > >> > > > can easily generate classes at runtime if necessary. > > > > > >> > > > > > > > > >> > > > How can I go about this? > > > > > >> > > > > > > > > >> > > > Thanks, > > > > > >> > > > > > > > > >> > > > Patrick > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > > > > > > >
