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

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

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

stephenconnolly
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]
------------------------------------------------------------------------

Is this just a whole new set of bugs that I have found?

Does this alter how we think things should work?

Right now I am unclear as to whether we should go ahead with releasing
3.5.1 given the effects of MNG-6209... at least in terms of exposing some
strangeness in the classloaders

On 16 September 2017 at 03:51, Stephen Connolly <
[hidden email]> wrote:

>
> On Sat 16 Sep 2017 at 10:51, Stephen Connolly <
> [hidden email]> wrote:
>
>> On Sat 16 Sep 2017 at 04:07, Igor Fedorenko <[hidden email]> wrote:
>>
>>> I don't really have much to add, but let me answer anyways :-)
>>>
>>> 1) I am reasonably confident we can compensate for the new classloader
>>> arrangement in m2e without much problems. The new setup does make plugin
>>> runtime classpath less stable, so there are likely other scenarios where
>>> plugins will behave differently (bad). On the other hand, I don't see
>>> any better way to support ServiceLoader. For java 8 it may be possible
>>> to use foreign-import of extensions classloader to fix MNG-6275, but
>>> that classloader was removed in java 9, unless I am mistaken.
>>
>>
>> Ok so I think the consensus is 6275 is probably a necessary fix for Java
>> 8 interoperability, but may expose bugs in plugins that made incorrect
>> assumptions, and is a breaking change from the PoV of the eclipse
>> integration. Netbeans is fine and IntelliJ seems to do its own think (given
>> I have an open bug that suggests IntelliJ is ignorant of the extensions
>> type mapping)
>>
>>
>>>
>>> 2) I believe TCCL is already set to project realm for projects that have
>>> extensions (and to plugin realm otherwise) during plugin execution.
>>
>>
>> So my question is why should TCCL *ever* be anything other than project
>> realm?
>>
>> The pom reference says:
>>
>>    - *extensions*: true or false, whether or not to load extensions of
>>    this plugin. It is by default false. Extensions are covered later in this
>>    document.
>>
>> It does not say that this flag affects the classloader of the plugin,
>> rather to me says when true the project realm shall include the plugin's
>> extensions.
>>
>> My understanding was that a plugin would always see its own extensions,
>> but if you set this flag then the project would be able to see them too...
>>
>> Now granted my understanding may be incorrect, but this change seems to
>> be turning things in an entirely different direction
>>
>
> Ok discussed this on #maven-dev
>
> I need to confirm my analysis, but if correct, then the fix for MNG-6209
> is correct... will need careful release noting
>
>>
>> Problem is, neither project realm nor any of the plugin realms have
>>> access to jvm extensions classloader, so ServiceLoader can't get classes
>>> from there.
>>
>>
>> That is another set of issues... but this should have been fixed by 6275
>> unless I am mistaken
>>
>>
>>>
>>> --
>>> Regards,
>>> Igor
>>>
>>> On Fri, Sep 15, 2017, at 12:09 PM, Stephen Connolly wrote:
>>> > I'm going to hold off closing the vote over the weekend to give Igor a
>>> > chance to:
>>> >
>>> > 1. comment on whether we need an alternative fix for MNG-6275 (and
>>> indeed
>>> > ideally provide one ;- );
>>> > 2. comment on whether the fix for MNG-6209 is exposing bugs in plugins
>>> > that
>>> > made incorrect assumptions about TCCL, or whether the fix is invalid or
>>> > even incomplete (I wonder if TCCL should always be
>>> > project.getClassRealm()
>>> > as extensions should be available to all plugins not just those that
>>> > declare they are providing extensions - unless I misunderstand)
>>> >
>>> > Once I have the required information I will be better able to assess
>>> > whether we should release 3.5.1 and follow up with a quick 3.5.2 or
>>> just
>>> > drop 3.5.1 and go straight to 3.5.2.
>>> >
>>> > -Stephen
>>> >
>>> > On 15 September 2017 at 05:45, Igor Fedorenko <[hidden email]>
>>> > wrote:
>>> >
>>> > > Has anyone tried wiring jvm extensions ClassLoader as foreign import
>>> to
>>> > > plugin/extensions realms? Jvm extensions classloader is little
>>> tricky to
>>> > > get to (see how this is done in java.util.ServiceLoader.
>>> loadInstalled),
>>> > > but I think this will solve ServiceLoader/MNG-6275 without polluting
>>> > > plugin classpath too much.
>>> > >
>>> > > --
>>> > > Regards,
>>> > > Igor
>>> > >
>>> > > On Fri, Sep 15, 2017, at 08:32 AM, Mark Derricutt wrote:
>>> > > > Would it be possible to handle this in a somewhat similar way to
>>> > > > threadSafe
>>> > > > mojos - some form of plugin flag that says "extensionSafe" [1],
>>> that if
>>> > > > the
>>> > > > plugin has <extensions>true</extensions> declared and doesn't
>>> declare
>>> > > > itself as being extensionSafe/extensionAware then we log a build
>>> warning
>>> > > > -
>>> > > > it wouldn't solve anything, other than giving some feedback to
>>> users some
>>> > > > indication of WHY their build fails under 3.5.1 - and to either
>>> remove
>>> > > > <extensions> or fix/update their plugins.
>>> > > >
>>> > > > [1] Or even just infer the applicability of extensions by the
>>> presence of
>>> > > > custom lifecycles, or Mojos implementing the extension interfaces
>>> ( it's
>>> > > > midnight, and a hazy tired thought ).
>>> > > >
>>> > > > --
>>> > > > "Great artists are extremely selfish and arrogant things" — Steven
>>> > > > Wilson,
>>> > > > Porcupine Tree
>>> > > >
>>> > > > On Sat, Sep 16, 2017 at 12:22 AM, Anders Hammar <[hidden email]
>>> >
>>> > > > wrote:
>>> > > >
>>> > > > > Based on Igor's feedback I'm changing my vote to +1.
>>> > > > >
>>> > > > > Having this class loader change in a bug fix release is probably
>>> not
>>> > > > > (semver) ideal though.
>>> > > > >
>>> > > > > /Anders
>>> > > > >
>>> > > > > On Fri, Sep 15, 2017 at 2:12 PM, Igor Fedorenko <
>>> [hidden email]>
>>> > > > > wrote:
>>> > > > >
>>> > > > > > I answered in more details on m2e-dev, but I believe we can
>>> > > compensate
>>> > > > > > for the change from m2e end. In the worst case we'll bundle
>>> hacked
>>> > > > > > version of DefaultClassRealmManager with m2e, not ideal, but
>>> not the
>>> > > end
>>> > > > > > of the world either.
>>> > > > > >
>>> > > > > > --
>>> > > > > > Regards,
>>> > > > > > Igor
>>> > > > > >
>>> > > > > > On Fri, Sep 15, 2017, at 07:21 AM, Anders Hammar wrote:
>>> > > > > > > On Fri, Sep 15, 2017 at 8:29 AM, Anders Hammar <
>>> [hidden email]>
>>> > > > > > wrote:
>>> > > > > > >
>>> > > > > > > > Reporting back from tests of m2e with embedded Maven
>>> 3.5.1, we
>>> > > see
>>> > > > > > problem
>>> > > > > > > > with the jaxws-maven-plugin mojo. We're two people seeing
>>> the
>>> > > issue
>>> > > > > > > > independently, but unfortunately Fred Bricon hasn't been
>>> able to
>>> > > > > > reproduce.
>>> > > > > > > >
>>> > > > > > >
>>> > > > > > > To follow up on this, my tests indicate that Maven 3.5.1
>>> causes
>>> > > changed
>>> > > > > > > class loading that could cause issues for plugins in m2e.
>>> I've
>>> > > asked
>>> > > > > for
>>> > > > > > > input from the m2e devs if it is possible to handle in m2e
>>> but they
>>> > > > > > > haven't
>>> > > > > > > responded yet.
>>> > > > > > >
>>> > > > > > > /Anders
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > >
>>> > > > > > > > So currently I'm 0 on the voting but I'll investigate some
>>> more.
>>> > > > > > > >
>>> > > > > > > > /Anders
>>> > > > > > > >
>>> > > > > > > > On Wed, Sep 13, 2017 at 9:26 AM, Anders Hammar <
>>> > > [hidden email]>
>>> > > > > > wrote:
>>> > > > > > > >
>>> > > > > > > >>
>>> > > > > > > >>
>>> > > > > > > >> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
>>> > > > > > > >> [hidden email]> wrote:
>>> > > > > > > >>
>>> > > > > > > >>> Have we got any feedback from the embedder integrations
>>> yet?
>>> > > > > > > >>>
>>> > > > > > > >>
>>> > > > > > > >> I haven't heard anything from the m2e people. Maybe we
>>> need to
>>> > > ping
>>> > > > > > them
>>> > > > > > > >> directly. I can contact Fred Bricon.
>>> > > > > > > >>
>>> > > > > > > >> /Anders
>>> > > > > > > >>
>>> > > > > > > >>
>>> > > > > > > >>>
>>> > > > > > > >>> On Mon 11 Sep 2017 at 22:57, Hervé BOUTEMY <
>>> > > [hidden email]>
>>> > > > > > > >>> wrote:
>>> > > > > > > >>>
>>> > > > > > > >>> > just for the records: it is Windows + Git Bash
>>> (MINGW64) only
>>> > > > > > > >>> >
>>> > > > > > > >>> > and there is a chance that adding -Djansi.force=true
>>> can
>>> > > force
>>> > > > > > JAnsi
>>> > > > > > > >>> > activation (even if JAnsi fails to detect that it
>>> should
>>> > > > > > auto-activate)
>>> > > > > > > >>> >
>>> > > > > > > >>> > details on issue in https://issues.apache.org/
>>> > > > > jira/browse/MNG-6282
>>> > > > > > ,
>>> > > > > > > >>> and a
>>> > > > > > > >>> > future JAnsi issue...
>>> > > > > > > >>> >
>>> > > > > > > >>> > Regards,
>>> > > > > > > >>> >
>>> > > > > > > >>> > Hervé
>>> > > > > > > >>> >
>>> > > > > > > >>> > Le lundi 11 septembre 2017, 12:53:46 CEST Stephen
>>> Connolly a
>>> > > > > écrit
>>> > > > > > :
>>> > > > > > > >>> > > So that is windows only, or were they lost on other
>>> OSes
>>> > > for
>>> > > > > you.
>>> > > > > > > >>> > >
>>> > > > > > > >>> > > I have colours on linux (via docker) and os-x
>>> > > > > > > >>> > >
>>> > > > > > > >>> > > On 11 September 2017 at 12:35, [hidden email] <
>>> > > > > > > >>> [hidden email]>
>>> > > > > > > >>> > >
>>> > > > > > > >>> > > wrote:
>>> > > > > > > >>> > > > +1 (conditionally).
>>> > > > > > > >>> > > >
>>> > > > > > > >>> > > > Tested via project that includes dozen of plugins:
>>> 1st
>>> > > tier,
>>> > > > > > > >>> MojoHaus
>>> > > > > > > >>> > and
>>> > > > > > > >>> > > > few 3rd party plugins (so to say).
>>> > > > > > > >>> > > >
>>> > > > > > > >>> > > > Everything looks good with one notable regression:
>>> > > > > > > >>> > > > https://issues.apache.org/jira/browse/MNG-6282
>>> Console
>>> > > > > output
>>> > > > > > has
>>> > > > > > > >>> no
>>> > > > > > > >>> > > > colors (regression in Maven 3.5.1)
>>> > > > > > > >>> > > >
>>> > > > > > > >>> > > > Regards,
>>> > > > > > > >>> > > > Dejan
>>> > > > > > > >>> > > >
>>> > > > > > > >>> > > > On 2017-09-10 17:39, Stephen Connolly <
>>> > > > > > > >>> [hidden email]
>>> > > > > > > >>> > >
>>> > > > > > > >>> > > >
>>> > > > > > > >>> > > > wrote:
>>> > > > > > > >>> > > > > Hi,
>>> > > > > > > >>> > > > >
>>> > > > > > > >>> > > > > We solved 25 issues:
>>> > > > > > > >>> > > > > https://issues.apache.org/
>>> jira/secure/ReleaseNote.jspa
>>> > > ?
>>> > > > > > > >>> > > >
>>> > > > > > > >>> > > > version=12338964&styleName=Text&projectId=12316922
>>> > > > > > > >>> > > >
>>> > > > > > > >>> > > > > There are 350 issues left in JIRA for Maven core:
>>> > > > > > > >>> > > > > https://issues.apache.org/
>>> jira/issues/?jql=project%20%
>>> > > > > > > >>> > > >
>>> > > > > > > >>> > > > 3D%20MNG%20AND%20resolution%
>>> 20%3D%20Unresolved%20ORDER%
>>> > > > > > > >>> > > > 20BY%20due%20ASC%2C%20priority%20DESC%2C%
>>> 20created%20ASC
>>> > > > > > > >>> > > >
>>> > > > > > > >>> > > > > Staging repo:
>>> > > > > > > >>> > > > > https://repository.apache.org/
>>> > > content/repositories/maven-
>>> > > > > > 1364/
>>> > > > > > > >>> > > > >
>>> > > > > > > >>> > > > > The distributable binaries and sources can be
>>> found
>>> > > here:
>>> > > > > > > >>> > > > > https://repository.apache.org/
>>> > > content/repositories/maven->
>>> > > > > >
>>> > > > > > > >>> > > > 1364/org/apache/maven/apache-maven/3.5.1/
>>> > > > > > > >>> > > >
>>> > > > > > > >>> > > > > Specifically the zip, tarball and source
>>> archives can
>>> > > be
>>> > > > > > found
>>> > > > > > > >>> here:
>>> > > > > > > >>> > > > > https://repository.apache.org/
>>> > > content/repositories/maven->
>>> > > > > >
>>> > > > > > > >>> > > > 1364/org/apache/maven/apache-
>>> > > maven/3.5.1/apache-maven-3.5.1-
>>> > > > > > > >>> bin.zip
>>> > > > > > > >>> > > >
>>> > > > > > > >>> > > > > https://repository.apache.org/
>>> > > content/repositories/maven->
>>> > > > > >
>>> > > > > > > >>> > > > 1364/org/apache/maven/apache-
>>> > > maven/3.5.1/apache-maven-3.5.1-
>>> > > > > > > >>> bin.tar.gz
>>> > > > > > > >>> > > >
>>> > > > > > > >>> > > > > https://repository.apache.org/
>>> > > content/repositories/maven->
>>> > > > > >
>>> > > > > > > >>> > > > 1364/org/apache/maven/apache-
>>> > > maven/3.5.1/apache-maven-3.5.1-
>>> > > > > > > >>> src.zip
>>> > > > > > > >>> > > >
>>> > > > > > > >>> > > > > https://repository.apache.org/
>>> > > content/repositories/maven->
>>> > > > > >
>>> > > > > > > >>> > > > 1364/org/apache/maven/apache-
>>> > > maven/3.5.1/apache-maven-3.5.1-
>>> > > > > > > >>> src.tar.gz
>>> > > > > > > >>> > > >
>>> > > > > > > >>> > > > > Source release checksum(s):
>>> > > > > > > >>> > > > > apache-maven-3.5.1-src.tar.gz sha1:
>>> > > > > > > >>> 9eb821f153c7667194aa11ccd099b7
>>> > > > > > > >>> > > >
>>> > > > > > > >>> > > > bd2059560d
>>> > > > > > > >>> > > >
>>> > > > > > > >>> > > > > apache-maven-3.5.1-src.zip: sha1:
>>> > > > > > 121d54b045380a8a4895eb137970ab
>>> > > > > > > >>> > > >
>>> > > > > > > >>> > > > 69e698eb0e
>>> > > > > > > >>> > > >
>>> > > > > > > >>> > > > > Git tag:
>>> > > > > > > >>> > > > > https://git-wip-us.apache.org/
>>> repos/asf?p=maven.git;a=
>>> > > > > > commit;h=
>>> > > > > > > >>> > > >
>>> > > > > > > >>> > > > 094e4e31a5af55bb17be87675da41d9aeca062f3
>>> > > > > > > >>> > > >
>>> > > > > > > >>> > > > > Staging site:
>>> > > > > > > >>> > > > > https://maven.apache.org/
>>> components/ref/3-LATEST/
>>> > > > > > > >>> > > > >
>>> > > > > > > >>> > > > > Vote open for 72 hours.
>>> > > > > > > >>> > > > >
>>> > > > > > > >>> > > > > [ ] +1
>>> > > > > > > >>> > > > > [ ] +0
>>> > > > > > > >>> > > > > [ ] -1
>>> > > > > > > >>> > > > >
>>> > > > > > > >>> > > > > Thanks,
>>> > > > > > > >>> > > > >
>>> > > > > > > >>> > > > > Stephen.
>>> > > > > > > >>> > > >
>>> > > > > > > >>> > > > ------------------------------
>>> > > ------------------------------
>>> > > > > > > >>> ---------
>>> > > > > > > >>> > > > To unsubscribe, e-mail:
>>> [hidden email]
>>> > > > > > > >>> > > > For additional commands, e-mail:
>>> > > [hidden email]
>>> > > > > > > >>> >
>>> > > > > > > >>> >
>>> > > > > > > >>> >
>>> > > > > > > >>> > ------------------------------
>>> ------------------------------
>>> > > > > > ---------
>>> > > > > > > >>> > To unsubscribe, e-mail: [hidden email].
>>> org
>>> > > > > > > >>> > 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
>>
> --
> Sent from my phone
>
Reply | Threaded
Open this post in threaded view
|

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

Chas Honton
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]

Reply | Threaded
Open this post in threaded view
|

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

stephenconnolly
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]
>
>
Reply | Threaded
Open this post in threaded view
|

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

stephenconnolly
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]

--
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

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

rfscholte
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]

Reply | Threaded
Open this post in threaded view
|

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

rfscholte
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]