Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

Igor Fedorenko-3
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

--
Regards,
Igor

On Mon, Sep 18, 2017, at 11:46 AM, Stephen Connolly wrote:

> Oh if only... there is some subtleties going on here.
>
> Classes are managed by the "plexus" / "classworlds" stuff, so you cannot
> override core classes etc.
>
> The problem is what extensions are visible and from which classloader
>
> On 18 September 2017 at 08:42, Charles Honton <[hidden email]> wrote:
>
> > From a security perspective, I would expect that core classes can not be
> > overridden by extensions or plugins.  Likewise, extension classes can not
> > be overridden by plugins.
> >
> > Given the use case of defaulting resources, I would expect that the plugin
> > resources are first, followed by plugin specific extensions, followed by
> > global extensions, finally core maven.  (This allows resources to be
> > specialized.)
> >
> > regards,
> > chas
> >
> > > On Sep 18, 2017, at 3:20 AM, Stephen Connolly <
> > [hidden email]> wrote:
> > >
> > > Hmmm, so I did some experiments:
> > >
> > > If you want to ride along, the experiments are at:
> > >
> > > https://github.com/stephenc/mng-6209
> > >
> > > So basically I have a plugin that does three different tests:
> > >
> > >        getLog().info("Injected by @Component:");
> > >        for (Lifecycle l : lifecycles) {
> > >            if (l.getId().startsWith("mng-6209-")) {
> > >                getLog().info("  " + l.getId().substring(9));
> > >            }
> > >        }
> > >        getLog().info("");
> > >        getLog().info("On Plugin Class Loader:");
> > >        try {
> > >            ClassLoader tccl = ListMojo.class.getClassLoader();
> > >            for (URL url :
> > > Collections.list(tccl.getResources("META-INF/probe.txt"))) {
> > >                InputStream is = url.openStream();
> > >                try {
> > >                    getLog().info("  " + IOUtil.toString(is).trim());
> > >                } finally {
> > >                    is.close();
> > >                }
> > >            }
> > >        } catch (IOException e) {
> > >            throw new MojoExecutionException(e.getMessage(), e);
> > >        }
> > >        getLog().info("");
> > >        getLog().info("On Thread Context Class Loader:");
> > >        try {
> > >            ClassLoader tccl =
> > > Thread.currentThread().getContextClassLoader();
> > >            for (URL url :
> > > Collections.list(tccl.getResources("META-INF/probe.txt"))) {
> > >                InputStream is = url.openStream();
> > >                try {
> > >                    getLog().info("  " + IOUtil.toString(is).trim());
> > >                } finally {
> > >                    is.close();
> > >                }
> > >            }
> > >        } catch (IOException e) {
> > >            throw new MojoExecutionException(e.getMessage(), e);
> > >        }
> > >
> > >
> > > First off, I hijack the @Component injection with some fake "lifecycles"
> > to
> > > see what "plexus" exposes to the plugins.
> > >
> > > Second, I look at the resources visible from the plugin's classloader.
> > >
> > > Finally, I look at the resources visible from the TCCL.
> > >
> > > Here's what 3.5.0 outputs:
> > >
> > > [INFO]
> > > ------------------------------------------------------------------------
> > > [INFO] Building Both extensions. Order: plugin1, plugin2 1.0-SNAPSHOT
> > > [INFO]
> > > ------------------------------------------------------------------------
> > > [INFO]
> > > [INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe1 ---
> > > [INFO] Injected by @Component:
> > > [INFO]   plugin1
> > > [INFO]
> > > [INFO] On Plugin Class Loader:
> > > [INFO]   plugin1
> > > [INFO]
> > > [INFO] On Thread Context Class Loader:
> > > [INFO]   plugin1
> > > [INFO]
> > > [INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe1 ---
> > > [INFO] Injected by @Component:
> > > [INFO]   plugin2
> > > [INFO]
> > > [INFO] On Plugin Class Loader:
> > > [INFO]   plugin2
> > > [INFO]
> > > [INFO] On Thread Context Class Loader:
> > > [INFO]   plugin2
> > > [INFO]
> > > [INFO]
> > > ------------------------------------------------------------------------
> > > [INFO] Building Only plugin1 extensions. Order: plugin1, plugin2
> > > 1.0-SNAPSHOT
> > > [INFO]
> > > ------------------------------------------------------------------------
> > > [INFO]
> > > [INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe2 ---
> > > [INFO] Injected by @Component:
> > > [INFO]   plugin1
> > > [INFO]
> > > [INFO] On Plugin Class Loader:
> > > [INFO]   plugin1
> > > [INFO]
> > > [INFO] On Thread Context Class Loader:
> > > [INFO]   plugin1
> > > [INFO]
> > > [INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe2 ---
> > > [INFO] Injected by @Component:
> > > [INFO]   plugin2
> > > [INFO]   plugin1
> > > [INFO]   extjar2
> > > [INFO]   extjar1
> > > [INFO]
> > > [INFO] On Plugin Class Loader:
> > > [INFO]   plugin2
> > > [INFO]   extjar2
> > > [INFO]   extjar1
> > > [INFO]
> > > [INFO] On Thread Context Class Loader:
> > > [INFO]   plugin2
> > > [INFO]   extjar2
> > > [INFO]   extjar1
> > > [INFO]
> > > [INFO]
> > > ------------------------------------------------------------------------
> > > [INFO] Building Both extensions. Order: plugin2, plugin1 1.0-SNAPSHOT
> > > [INFO]
> > > ------------------------------------------------------------------------
> > > [INFO]
> > > [INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe3 ---
> > > [INFO] Injected by @Component:
> > > [INFO]   plugin2
> > > [INFO]
> > > [INFO] On Plugin Class Loader:
> > > [INFO]   plugin2
> > > [INFO]
> > > [INFO] On Thread Context Class Loader:
> > > [INFO]   plugin2
> > > [INFO]
> > > [INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe3 ---
> > > [INFO] Injected by @Component:
> > > [INFO]   plugin1
> > > [INFO]
> > > [INFO] On Plugin Class Loader:
> > > [INFO]   plugin1
> > > [INFO]
> > > [INFO] On Thread Context Class Loader:
> > > [INFO]   plugin1
> > > [INFO]
> > > [INFO]
> > > ------------------------------------------------------------------------
> > > [INFO] Building Both extensions. Order: plugin1, plugin2. Extra
> > dependency
> > > in plugin1 1.0-SNAPSHOT
> > > [INFO]
> > > ------------------------------------------------------------------------
> > > [INFO]
> > > [INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe4 ---
> > > [INFO] Injected by @Component:
> > > [INFO]   extjar2
> > > [INFO]   plugin1
> > > [INFO]
> > > [INFO] On Plugin Class Loader:
> > > [INFO]   plugin1
> > > [INFO]   extjar2
> > > [INFO]
> > > [INFO] On Thread Context Class Loader:
> > > [INFO]   plugin1
> > > [INFO]   extjar2
> > > [INFO]
> > > [INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe4 ---
> > > [INFO] Injected by @Component:
> > > [INFO]   plugin2
> > > [INFO]
> > > [INFO] On Plugin Class Loader:
> > > [INFO]   plugin2
> > > [INFO]
> > > [INFO] On Thread Context Class Loader:
> > > [INFO]   plugin2
> > > [INFO]
> > > ------------------------------------------------------------------------
> > >
> > > Now if we run with 3.5.1 (which contains the fix for MNG-6209)
> > >
> > > [INFO]
> > > ------------------------------------------------------------------------
> > > [INFO] Building Both extensions. Order: plugin1, plugin2 1.0-SNAPSHOT
> > > [INFO]
> > > ------------------------------------------------------------------------
> > > [INFO]
> > > [INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe1 ---
> > > [INFO] Injected by @Component:
> > > [INFO]   plugin2
> > > [INFO]   plugin1
> > > [INFO]   extjar2
> > > [INFO]   extjar1
> > >
> > > I would have expected the sequence to be: /build/extensions in pom order
> > > followed by /build/plugins/plugin[extensions=true] in pom order. This
> > seems
> > > to be the reverse order. Is this a bug?
> > >
> > > [INFO]
> > > [INFO] On Plugin Class Loader:
> > > [INFO]   plugin1
> > >
> > > We haven't changed how the plugin classloader gets instantiated in
> > > MNG-6209. It seems strange to me that this excludes the
> > > /build/extensions... on the other hand this could be a side-effect of how
> > > the classloader gets instantiated (which would mean using the plugin's
> > > classloader is probably a bad idea, perhaps we need to provide the
> > ability
> > > to inject the classloader as a @Component or something)
> > >
> > > [INFO]
> > > [INFO] On Thread Context Class Loader:
> > > [INFO]   extjar1
> > > [INFO]   extjar2
> > >
> > > OK, we see the change vs 3.5.0 as this is now the project realm...
> > though I
> > > would have expected the project realm to also include the plugins that
> > were
> > > marked as extensions...
> > >
> > > [INFO]
> > > [INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe1 ---
> > > [INFO] Injected by @Component:
> > > [INFO]   plugin2
> > > [INFO]   plugin1
> > > [INFO]   extjar2
> > > [INFO]   extjar1
> > > [INFO]
> > > [INFO] On Plugin Class Loader:
> > > [INFO]   plugin2
> > > [INFO]
> > > [INFO] On Thread Context Class Loader:
> > > [INFO]   extjar1
> > > [INFO]   extjar2
> > > [INFO]
> > > [INFO]
> > > ------------------------------------------------------------------------
> > > [INFO] Building Only plugin1 extensions. Order: plugin1, plugin2
> > > 1.0-SNAPSHOT
> > > [INFO]
> > > ------------------------------------------------------------------------
> > > [INFO]
> > > [INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe2 ---
> > > [INFO] Injected by @Component:
> > > [INFO]   plugin1
> > > [INFO]   extjar2
> > > [INFO]   extjar1
> > >
> > > As expected, given that plugin2 is not an extension here (apart from the
> > > order being reverse of what I expect)
> > >
> > > [INFO]
> > > [INFO] On Plugin Class Loader:
> > > [INFO]   plugin1
> > > [INFO]
> > > [INFO] On Thread Context Class Loader:
> > > [INFO]   extjar2
> > > [INFO]   extjar1
> > > [INFO]
> > > [INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe2 ---
> > > [INFO] Injected by @Component:
> > > [INFO]   plugin2
> > > [INFO]   plugin1
> > > [INFO]   extjar2
> > > [INFO]   extjar1
> > >
> > > As expected (modulo order) because a plugin should see any self-defined
> > > extensions. I would expect the order to be plugin2, extjar1, extjar2,
> > > plugin1 (because the plugin is not an extension, it should have its
> > > extensions as priority over the project realms's)
> > >
> > > [INFO]
> > > [INFO] On Plugin Class Loader:
> > > [INFO]   plugin2
> > > [INFO]   extjar2
> > > [INFO]   extjar1
> > >
> > > WAT! ok, this I do not understand. Something is wrong somewhere, either
> > > plugin1's classloader should also include extjar2 and extjar1 or this one
> > > shouldn't. And since we have extjar1 and extjar2 where is plugin1? (if
> > the
> > > inclusion is correct here I expect plugin2, extjar1, extjar2, plugin1 as
> > a
> > > plugin that is not an extension plugin should have its own implementation
> > > first followed then by /build/extensions in pom order and then
> > > /build/plugins/plugin[extension==true]
> > >
> > > This is making no sense at all!
> > >
> > > [INFO]
> > > [INFO] On Thread Context Class Loader:
> > > [INFO]   plugin2
> > > [INFO]   extjar2
> > > [INFO]   extjar1
> > >
> > > So TCCL is the plugin classloader here as expected
> > >
> > > [INFO]
> > > [INFO]
> > > ------------------------------------------------------------------------
> > > [INFO] Building Both extensions. Order: plugin2, plugin1 1.0-SNAPSHOT
> > > [INFO]
> > > ------------------------------------------------------------------------
> > > [INFO]
> > > [INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe3 ---
> > > [INFO] Injected by @Component:
> > > [INFO]   plugin2
> > > [INFO]   plugin1
> > > [INFO]   extjar2
> > > [INFO]   extjar1
> > >
> > > I note that the change in pom order has had no effect on the component
> > > sequence. This leads me to suspect that plexus has some rule that is
> > > defining the sequencing... it would be good if we could document that
> > > somewhere...
> > >
> > > [INFO]
> > > [INFO] On Plugin Class Loader:
> > > [INFO]   plugin2
> > > [INFO]
> > > [INFO] On Thread Context Class Loader:
> > > [INFO]   extjar2
> > > [INFO]   extjar1
> > > [INFO]
> > > [INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe3 ---
> > > [INFO] Injected by @Component:
> > > [INFO]   plugin2
> > > [INFO]   plugin1
> > > [INFO]   extjar2
> > > [INFO]   extjar1
> > > [INFO]
> > > [INFO] On Plugin Class Loader:
> > > [INFO]   plugin1
> > > [INFO]
> > > [INFO] On Thread Context Class Loader:
> > > [INFO]   extjar2
> > > [INFO]   extjar1
> > > [INFO]
> > > [INFO]
> > > ------------------------------------------------------------------------
> > > [INFO] Building Both extensions. Order: plugin1, plugin2. Extra
> > dependency
> > > in plugin1 1.0-SNAPSHOT
> > > [INFO]
> > > ------------------------------------------------------------------------
> > > [INFO]
> > > [INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe4 ---
> > > [INFO] Injected by @Component:
> > > [INFO]   plugin1
> > > [INFO]   extjar2
> > > [INFO]   plugin2
> > > [INFO]   extjar2
> > > [INFO]   extjar1
> > >
> > > WAT! seems that @Component is somewhat in random order, in this case we
> > > have modified the dependencies if plugin1 to also include extjar2, the
> > > order I would expect is:
> > >
> > > extjar1, extjar2, plugin1, extjar2, plugin2
> > >
> > > Given the previous executions and the fact that changing the sequence of
> > > plugin1 and plugin2 in the pom did not affect the previous executions, if
> > > plexus had a deterministic ordering then I would have been somewhat OK
> > with:
> > >
> > > plugin2, plugin1, extjar2, extjar2, extjar1
> > >
> > > But this seems to suggest that we have a completely non-deterministic
> > > ordering... that is not good for reproducible builds...
> > >
> > > [INFO]
> > > [INFO] On Plugin Class Loader:
> > > [INFO]   plugin1
> > > [INFO]   extjar2
> > >
> > > Now we see extjar2 but only because it has been explicitly added to the
> > > plugins dependencies, IMHO it should be here twice, e.g.
> > >
> > > extjar1, extjar2, plugin1, extjar2, plugin2
> > >
> > > But it seems acceptable if this is instead plugin1, extjar2 (though it
> > > makes the plugin classloader useless for discovery)
> > >
> > > [INFO]
> > > [INFO] On Thread Context Class Loader:
> > > [INFO]   extjar1
> > > [INFO]   extjar2
> > > [INFO]
> > > [INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe4 ---
> > > [INFO] Injected by @Component:
> > > [INFO]   plugin1
> > > [INFO]   extjar2
> > > [INFO]   plugin2
> > > [INFO]   extjar2
> > > [INFO]   extjar1
> > > [INFO]
> > > [INFO] On Plugin Class Loader:
> > > [INFO]   plugin2
> > > [INFO]
> > > [INFO] On Thread Context Class Loader:
> > > [INFO]   extjar1
> > > [INFO]   extjar2
> > > [INFO]
> > > ------------------------------------------------------------------------
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

rfscholte
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 <[hidden email]>  
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: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

stephenconnolly
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 <[hidden email]> 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
> > <[hidden email]> 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 <[hidden email]>
> 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 <
> [hidden email]>
> > >> 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: [hidden email]
> > >> For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

Igor Fedorenko-3
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.

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

--
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 <[hidden email]> 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
> > > <[hidden email]> 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 <[hidden email]>
> > 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 <
> > [hidden email]>
> > > >> 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: [hidden email]
> > > >> For additional commands, e-mail: [hidden email]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> > --
> Sent from my phone

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

Igor Fedorenko-3
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 <[hidden email]> 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 <[hidden email]> 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
> > > > > <[hidden email]> 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 <[hidden email]>
> > > > 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 <
> > > > [hidden email]>
> > > > > >> 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: [hidden email]
> > > > > >> For additional commands, e-mail: [hidden email]
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > > --
> > > Sent from my phone
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> > --
> Sent from my phone

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

rfscholte
In reply to this post by Igor Fedorenko-3
Are these questions we can/should answer within a couple of days?
I'm not aware of somebody hitting the regression as caused by MNG-5742  
other than Igor.
However, we've seen a couple of changed behavior clearly caused by  
MNG-6209 (not answering if this intended or not)

We could also make the decision to leave MNG-6209 out, do a new release  
and complete our investigation directly afterwards.
This change is way too tricky to do additional changes under pressure.

thanks,
Robert


On Sun, 24 Sep 2017 18:07:39 +0200, Stephen Connolly  
<[hidden email]> wrote:

> https://maven.apache.org/guides/mini/guide-maven-classloading.html says:
>
>> When a build plugin is executed, the thread's context classloader is set
> to the plugin classloader.
>
> So we'll need to fix something somewhere...
>
> https://svn.apache.org/repos/infra/websites/production/maven/content/reference/maven-classloading.html
> is unaccessible from the website due to a rewrite rule...
>
> Things that seem to be missing:
>
> * What is the desired classloading for a plugin that is marked as an
> extension? Can a plugin have a META-INF/maven/extension.xml to allow
> exporting classes and artifacts when used as an extension? How should the
> classloading look for such a strange beast.
>
> * How does one access the plugin classloader if we want TCCL to be other
> than that, is it a Dependency Injection or something else?
>
> * What differentiates a Core extension from a Build extension (is it  
> that a
> build extension lacks a META-INF/maven/extension.xml and was only  
> declared
> in the pom.xml, while a core extension either has a
> META-INF/maven/extension.xml - if declared in the pom - or is an  
> extension
> declared in .mvn/extensions.xml)
>
> At this point in time I think we are nearing the point where I may have  
> to
> declare 3.5.1 abandoned as I think the classloading in that is a symptom  
> of
> too many cooks all changing things in different directions. We need a
> consistent vision of where we want things to go and - while we need not  
> get
> there in one go - the path presented for others to see.
>
> Things I think we should consider:
>
> 1. Do we want to formally deprecate Build Extensions and the
> /project/build/extensions element (start logging warnings, etc)?
> 2. Do we want to formally deprecate plugins as extensions and start  
> logging
> warnings for
> /project/build/(pluginManagement|.)/plugins/plugin/extensions[text()==true]
> 3. What is the difference in classloading for a /project/build/extensions
> which has a META-INF/maven/extension.xml and one that doesn't?
>
> I'm keeping the 3.5.1 release in staging until we get a clear vision for
> how we want to have classloading so that I can assess whether the 3.5.1
> actuality is only moving nearer to the vision (ok to release) or has  
> moved
> nearer in some ways but further in others (not ok to release)
>
> On 20 September 2017 at 12:44, Igor Fedorenko <[hidden email]>  
> wrote:
>
>> Real-world scm or wagon <extensions> won't trigger maven2-compat code
>> path [1]. To avoid that obscure code path we can either make the test
>> more elaborate (i.e. add dependencies to extjar1/extjar2) or we can use
>> extensions <plugin>. Either way I don't think we should spend time on
>> the code path unlikely to be used in real life.
>>
>> [1]
>> https://github.com/apache/maven/blob/maven-3.5.1/maven-
>> core/src/main/java/org/apache/maven/project/DefaultProjectBuildingHelper.
>> java#L210-L219
>>
>> --
>> Regards,
>> Igor
>>
>> On Wed, Sep 20, 2017, at 03:29 AM, Robert Scholte wrote:
>> > On Wed, 20 Sep 2017 09:12:47 +0200, Stephen Connolly
>> > <[hidden email]> wrote:
>> >
>> > > On Wed 20 Sep 2017 at 01:29, Igor Fedorenko <[hidden email]>
>> 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.
>> > >
>> >
>> > Not sure I agree with this. I think there are jars worth sharing  
>> across
>> > multiple plugins, but where making the plugin an extension is a bit
>> > weird.
>> > I'm thinking of scm and wagon in this case.
>> >
>> > >
>> > > 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 <[hidden email]>
>> > >> 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
>> > >> > > > <[hidden email]> 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
>> > >> <[hidden email]>
>> > >> > > 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 <
>> > >> > > [hidden email]>
>> > >> > > > >> 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: [hidden email]
>> > >> > > > >> For additional commands, e-mail: [hidden email]
>> > >> > > >
>> > >> > > >
>> > >>  
>> ---------------------------------------------------------------------
>> > >> > > > To unsubscribe, e-mail: [hidden email]
>> > >> > > > For additional commands, e-mail: [hidden email]
>> > >> > > >
>> > >> > >
>> > >> > >
>> > >>  
>> ---------------------------------------------------------------------
>> > >> > > To unsubscribe, e-mail: [hidden email]
>> > >> > > For additional commands, e-mail: [hidden email]
>> > >> > >
>> > >> > > --
>> > >> > Sent from my phone
>> > >>
>> > >>  
>> ---------------------------------------------------------------------
>> > >> To unsubscribe, e-mail: [hidden email]
>> > >> For additional commands, e-mail: [hidden email]
>> > >>
>> > >> --
>> > > Sent from my phone
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

stephenconnolly
On Sun 24 Sep 2017 at 17:44, Robert Scholte <[hidden email]> wrote:

> Are these questions we can/should answer within a couple of days?
> I'm not aware of somebody hitting the regression as caused by MNG-5742
> other than Igor.
> However, we've seen a couple of changed behavior clearly caused by
> MNG-6209 (not answering if this intended or not)
>
> We could also make the decision to leave MNG-6209 out, do a new release
> and complete our investigation directly afterwards.
> This change is way too tricky to do additional changes under pressure.


If we drop 3.5.1 i’d be in favour of reverting both MNG-6209 and MNG-6275
(the TCCL one) as I have found documentation stating that TCCL is the
plugin classloader, which makes me wary of changing that in a patch release
(but I can be convinced otherwise)


>
> thanks,
> Robert
>
>
> On Sun, 24 Sep 2017 18:07:39 +0200, Stephen Connolly
> <[hidden email]> wrote:
>
> > https://maven.apache.org/guides/mini/guide-maven-classloading.html says:
> >
> >> When a build plugin is executed, the thread's context classloader is set
> > to the plugin classloader.
> >
> > So we'll need to fix something somewhere...
> >
> >
> https://svn.apache.org/repos/infra/websites/production/maven/content/reference/maven-classloading.html
> > is unaccessible from the website due to a rewrite rule...
> >
> > Things that seem to be missing:
> >
> > * What is the desired classloading for a plugin that is marked as an
> > extension? Can a plugin have a META-INF/maven/extension.xml to allow
> > exporting classes and artifacts when used as an extension? How should the
> > classloading look for such a strange beast.
> >
> > * How does one access the plugin classloader if we want TCCL to be other
> > than that, is it a Dependency Injection or something else?
> >
> > * What differentiates a Core extension from a Build extension (is it
> > that a
> > build extension lacks a META-INF/maven/extension.xml and was only
> > declared
> > in the pom.xml, while a core extension either has a
> > META-INF/maven/extension.xml - if declared in the pom - or is an
> > extension
> > declared in .mvn/extensions.xml)
> >
> > At this point in time I think we are nearing the point where I may have
> > to
> > declare 3.5.1 abandoned as I think the classloading in that is a symptom
> > of
> > too many cooks all changing things in different directions. We need a
> > consistent vision of where we want things to go and - while we need not
> > get
> > there in one go - the path presented for others to see.
> >
> > Things I think we should consider:
> >
> > 1. Do we want to formally deprecate Build Extensions and the
> > /project/build/extensions element (start logging warnings, etc)?
> > 2. Do we want to formally deprecate plugins as extensions and start
> > logging
> > warnings for
> >
> /project/build/(pluginManagement|.)/plugins/plugin/extensions[text()==true]
> > 3. What is the difference in classloading for a /project/build/extensions
> > which has a META-INF/maven/extension.xml and one that doesn't?
> >
> > I'm keeping the 3.5.1 release in staging until we get a clear vision for
> > how we want to have classloading so that I can assess whether the 3.5.1
> > actuality is only moving nearer to the vision (ok to release) or has
> > moved
> > nearer in some ways but further in others (not ok to release)
> >
> > On 20 September 2017 at 12:44, Igor Fedorenko <[hidden email]>
> > wrote:
> >
> >> Real-world scm or wagon <extensions> won't trigger maven2-compat code
> >> path [1]. To avoid that obscure code path we can either make the test
> >> more elaborate (i.e. add dependencies to extjar1/extjar2) or we can use
> >> extensions <plugin>. Either way I don't think we should spend time on
> >> the code path unlikely to be used in real life.
> >>
> >> [1]
> >> https://github.com/apache/maven/blob/maven-3.5.1/maven-
> >>
> core/src/main/java/org/apache/maven/project/DefaultProjectBuildingHelper.
> >> java#L210-L219
> >>
> >> --
> >> Regards,
> >> Igor
> >>
> >> On Wed, Sep 20, 2017, at 03:29 AM, Robert Scholte wrote:
> >> > On Wed, 20 Sep 2017 09:12:47 +0200, Stephen Connolly
> >> > <[hidden email]> wrote:
> >> >
> >> > > On Wed 20 Sep 2017 at 01:29, Igor Fedorenko <[hidden email]>
> >> 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.
> >> > >
> >> >
> >> > Not sure I agree with this. I think there are jars worth sharing
> >> across
> >> > multiple plugins, but where making the plugin an extension is a bit
> >> > weird.
> >> > I'm thinking of scm and wagon in this case.
> >> >
> >> > >
> >> > > 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 <[hidden email]
> >
> >> > >> 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
> >> > >> > > > <[hidden email]> 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
> >> > >> <[hidden email]>
> >> > >> > > 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 <
> >> > >> > > [hidden email]>
> >> > >> > > > >> 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: [hidden email]
> >> > >> > > > >> For additional commands, e-mail:
> [hidden email]
> >> > >> > > >
> >> > >> > > >
> >> > >>
> >> ---------------------------------------------------------------------
> >> > >> > > > To unsubscribe, e-mail: [hidden email]
> >> > >> > > > For additional commands, e-mail: [hidden email]
> >> > >> > > >
> >> > >> > >
> >> > >> > >
> >> > >>
> >> ---------------------------------------------------------------------
> >> > >> > > To unsubscribe, e-mail: [hidden email]
> >> > >> > > For additional commands, e-mail: [hidden email]
> >> > >> > >
> >> > >> > > --
> >> > >> > Sent from my phone
> >> > >>
> >> > >>
> >> ---------------------------------------------------------------------
> >> > >> To unsubscribe, e-mail: [hidden email]
> >> > >> For additional commands, e-mail: [hidden email]
> >> > >>
> >> > >> --
> >> > > Sent from my phone
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: [hidden email]
> >> > For additional commands, e-mail: [hidden email]
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
Sent from my phone