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
