maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Fedorenko <i...@ifedorenko.com>
Subject Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)
Date Wed, 20 Sep 2017 11:31:44 GMT
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 <igor@ifedorenko.com> wrote:
> 
> > In that case, can I suggest couple of changes to the test project
> >
> > * I thinks it makes more sense to configure extjar1 and extjar2 as
> > extensions <plugin> elements in probleN pom.xml files. First, there is
> > no meaningful order between <extensions> and <plugins> elements. More
> > importantly, though, simple <extensions> are treated in special
> > maven2-compat mode and are not representative of likely real-world
> > extensions.
> 
> 
> That sounds like we need documentation updated then. None of that is
> obvious to me.
> 
> 
> >
> > * I think we should introduce META-INF/maven/extension.xml to the test
> > extensions. This metadata what introduced to configure classpath
> > visibility, so lets use it.
> 
> 
> Again, not obvious to me, if that file allows control of classpath
> visibility then it may be that the only issue *with* 3.5.1 is the lack of
> documentation... now previous versions would have been adding breaking
> changes from my PoV but that is the past and should not affect the 3.5.1
> release.
> 
> PRs for the probe project welcome. I am happy to try and write docs once
> I
> have an understanding of what the expected behaviours are
> 
> 
> >
> > --
> > Regards,
> > Igor
> >
> > On Tue, Sep 19, 2017, at 05:12 PM, Stephen Connolly wrote:
> > > Yes, the expectations are key. Depending on what they are we may either
> > > drop 3.5.1 or go ahead as it depends on whether this is more correct than
> > > 3.5.0 or swapping one fix for a bug
> > >
> > > On Tue 19 Sep 2017 at 21:39, Igor Fedorenko <igor@ifedorenko.com> wrote:
> > >
> > > > Just to confirm I understand what we are trying to establish here. We
> > > > want to decide the expected/desired component injection behaviour and
> > > > classpath visibility in the absence of package and artifact export
> > > > configuration (i.e. META-INF/maven/extension.xml file). Did I get this
> > > > right?
> > > >
> > > > --
> > > > Regards,
> > > > Igor
> > > >
> > > > On Tue, Sep 19, 2017, at 03:52 PM, Robert Scholte wrote:
> > > > > Let's do it like this:
> > > > >
> > > >
> > https://cwiki.apache.org/confluence/download/attachments/2329841/classrealms.pdf?api=v2
> > > > >
> > > > > Robert
> > > > >
> > > > > On Tue, 19 Sep 2017 21:08:39 +0200, Stephen Connolly
> > > > > <stephen.alan.connolly@gmail.com> wrote:
> > > > >
> > > > > > I think you will need a link to the PDF as attachments are stripped
> > > > from
> > > > > > the ML
> > > > > >
> > > > > > On Tue 19 Sep 2017 at 19:57, Robert Scholte <rfscholte@apache.org>
> > > > wrote:
> > > > > >
> > > > > >> Attached a single page overview.
> > > > > >>
> > > > > >> Per block you'll see in the upper left corner the executed
plugin
> > > > > >> The left column contains the extensions and plugin in orderas
> > > > specified
> > > > > >> in
> > > > > >> the pom.xml
> > > > > >> In every classloadercolumn you'll see numbers which represent
the
> > > > order.
> > > > > >>
> > > > > >> I hope I didn't make any mistakes.
> > > > > >> Tomorrow I have enough time to see if I understand what's
> > happening
> > > > > >> here.
> > > > > >>
> > > > > >> I will come back with my conclusions.
> > > > > >>
> > > > > >> Robert
> > > > > >>
> > > > > >> On Tue, 19 Sep 2017 06:55:08 +0200, Igor Fedorenko <
> > > > igor@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-unsubscribe@maven.apache.org
> > > > > >> For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > > --
> > > Sent from my phone
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > --
> Sent from my phone

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message