Just to confirm I understand what we are trying to establish here. We want to decide the expected/desired component injection behaviour and classpath visibility in the absence of package and artifact export configuration (i.e. META-INF/maven/extension.xml file). Did I get this right?
-- Regards, Igor On Tue, Sep 19, 2017, at 03:52 PM, Robert Scholte wrote: > Let's do it like this: > https://cwiki.apache.org/confluence/download/attachments/2329841/classrealms.pdf?api=v2 > > Robert > > On Tue, 19 Sep 2017 21:08:39 +0200, Stephen Connolly > <stephen.alan.conno...@gmail.com> wrote: > > > I think you will need a link to the PDF as attachments are stripped from > > the ML > > > > On Tue 19 Sep 2017 at 19:57, Robert Scholte <rfscho...@apache.org> wrote: > > > >> Attached a single page overview. > >> > >> Per block you'll see in the upper left corner the executed plugin > >> The left column contains the extensions and plugin in orderas specified > >> in > >> the pom.xml > >> In every classloadercolumn you'll see numbers which represent the order. > >> > >> I hope I didn't make any mistakes. > >> Tomorrow I have enough time to see if I understand what's happening > >> here. > >> > >> I will come back with my conclusions. > >> > >> Robert > >> > >> On Tue, 19 Sep 2017 06:55:08 +0200, Igor Fedorenko <i...@ifedorenko.com> > >> wrote: > >> > >> > TL;DR your test project exposed two existing bugs, one change in > >> > behaviour and one quirk I can't explain > >> > > >> > * Build `<extensions>` are loaded by two classloaders, which is a bug > >> in > >> > DefaultProjectBuildingHelper#createProjectRealm and explains why you > >> see > >> > extjar1/extjar2 in the output > >> > * ClassRealm does not allow same foreign-import from multiple > >> > classloaders, which is a bug and explains why it is not possible to > >> load > >> > same resource from multiple plugins/extensions > >> > * TCCL does not have access to private (i.e. not exported) resources > >> of > >> > this extensions plugin, which is a change of behaviour introduced by > >> > mng-6209 fix > >> > * Also, component injection order appears to be backwards, but maybe > >> > Stuart can explain why. > >> > > >> > > >> > Below is more detailed explanation of expected and observed behaviour > >> > > >> > > >> > ## Component injection depends on the currently running plugin and the > >> > injection site > >> > > >> > Currently running plugins have access to the following component > >> > implementations: > >> > > >> > * Regular plugin has access to components implemented by the plugin, > >> > project build extensions, if any (via project class realm foreign > >> > import) and Maven Core. > >> > * Extension plugin has access to components implemented by the project > >> > build extensions and Maven Core. > >> > * Without a running plugin (e.g., during project dependency > >> resolution), > >> > components implemented by the project build extensions and Maven Core > >> > are accessible. > >> > > >> > Different injection sites have access to the following component > >> > interfaces: > >> > > >> > * Maven Core has access to component interfaces defined by the core > >> > itself (obviously) > >> > * Project build extensions have access to **public** component > >> > interfaces defined by Maven Core and component interfaces defined by > >> the > >> > build extension itself (there is no way to access component interfaces > >> > defined in other extensions) > >> > * Regular plugins have access to **public** component interfaces > >> defined > >> > by Maven Core, component interfaces **exported** by build extensions > >> and > >> > component interfaces defined in the plugin itself > >> > > >> > For injection to work, injection site has to have access to the > >> > component interface and the component implementation must be > >> accessible > >> > through the current context. > >> > > >> > From what I can tell, in your example all plugins have access to the > >> > right components when using current 3.5.2-SNAPSHOT. The injection > >> order > >> > does appear to be backwards from what I expected, however. > >> > > >> > > >> > ## Resources lookup fully depends on classpath visibility, > >> specifically > >> > > >> > * Regular plugin class realm has access to resources from the plugin > >> > itself, from **exported** packages of the project build extensions and > >> > **public** Maven Core packages > >> > * Extensions plugin class realm has access to the resources from the > >> > extensions plugin itself and from **public** Maven Core packages > >> > * Project class realm has access to classes and resources **exported** > >> > by project build extensions and **public** Maven Core packages > >> > > >> > I see three problems here > >> > > >> > * Maven adds build single-jar `<extensions>` elements directly to > >> > project class realm **and** creates separate extensions class realms > >> for > >> > them. Which results in duplicate classes/resources loaded by two > >> > classloaders and explains why you see extjar1/extjar2 output (which > >> you > >> > shouldn't according to the explanation above) > >> > * ClassRealm does not allow foreign-import of the same package from > >> > multiple classloaders. This makes it impossible to load the same > >> > resource from multiple plugins/extensions. > >> > * Extensions plugins cannot access their own private (i.e. not > >> exported) > >> > resources via TCCL, this is change in behaviour introduced by mng-6209 > >> > fix > >> > > >> > Hope this helps > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
