Just to be clear, while I agree the documentation is lacking, neither special-casing "simple" <extensions> nor META-INF/maven/extension.xml is new behaviour in 3.5.1, both existed since 3.0 alphas iirc. Also, Hervé did add some extension.xml documentation couple of years ago.
https://issues.apache.org/jira/browse/MNG-4381 -- Regards, Igor On Wed, Sep 20, 2017, at 03:12 AM, Stephen Connolly wrote: > On Wed 20 Sep 2017 at 01:29, Igor Fedorenko <i...@ifedorenko.com> wrote: > > > In that case, can I suggest couple of changes to the test project > > > > * I thinks it makes more sense to configure extjar1 and extjar2 as > > extensions <plugin> elements in probleN pom.xml files. First, there is > > no meaningful order between <extensions> and <plugins> elements. More > > importantly, though, simple <extensions> are treated in special > > maven2-compat mode and are not representative of likely real-world > > extensions. > > > That sounds like we need documentation updated then. None of that is > obvious to me. > > > > > > * I think we should introduce META-INF/maven/extension.xml to the test > > extensions. This metadata what introduced to configure classpath > > visibility, so lets use it. > > > Again, not obvious to me, if that file allows control of classpath > visibility then it may be that the only issue *with* 3.5.1 is the lack of > documentation... now previous versions would have been adding breaking > changes from my PoV but that is the past and should not affect the 3.5.1 > release. > > PRs for the probe project welcome. I am happy to try and write docs once > I > have an understanding of what the expected behaviours are > > > > > > -- > > Regards, > > Igor > > > > On Tue, Sep 19, 2017, at 05:12 PM, Stephen Connolly wrote: > > > Yes, the expectations are key. Depending on what they are we may either > > > drop 3.5.1 or go ahead as it depends on whether this is more correct than > > > 3.5.0 or swapping one fix for a bug > > > > > > On Tue 19 Sep 2017 at 21:39, Igor Fedorenko <i...@ifedorenko.com> wrote: > > > > > > > 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 > > > > > > > > -- > > > Sent from my phone > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > -- > Sent from my phone --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org