Re: Polyglot usage of components/Dependency graph API

Yep, which means that the executioncontext of the plugin should also switch to the right tccl probably as you mentionned. Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github

Re: Polyglot usage of components/Dependency graph API

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 d

Re: Polyglot usage of components/Dependency graph API

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

Re: Polyglot usage of components/Dependency graph API

Both that and trying to simply get the Class. 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-rub

Re: Polyglot usage of components/Dependency graph API

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

Re: Polyglot usage of components/Dependency graph API

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

Re: Polyglot usage of components/Dependency graph API

irb(#):002:0> ctx.session.container => # 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

Re: Polyglot usage of components/Dependency graph API

*ctx.session.container* ? Le mar. 22 nov. 2022 à 16:23, Patrick Plenefisch 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 t

Re: Polyglot usage of components/Dependency graph API

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

Re: Polyglot usage of components/Dependency graph API

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

Polyglot usage of components/Dependency graph API

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 genera