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