Thanks Jason, that was most informative. But I am running into one issue and I am not sure whether it is a bug or by design.
I have a project that has no config for my plugin (containing a LifeCycleParticipant) and that project has a child module that does have config for my plugin. During LifeCycleParticipant#afterProjectsRead, session.getTopLevelProject().getClassRealm() is always null. And iterating over session.getProjects() any projects that do not have the plugin configured (including the parent project) will also have no ClassRealm. Is that expected? Shouldn't the top level project always have some ClassRealm? Should all projects? Another query that I couldn't resolve from Benjamin's doc. Should the classloader for a parent project contain those of the child modules or is there a single project classloader? William On Thu, May 22, 2014 at 12:18 AM, Jason van Zyl <[email protected]> wrote: > For why it fixes it you may want to take a look at the detailed > documentation Benjamin wrote while working on Maven 3: > > https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Class+Loading > > Extensions A and B in the diagrams are your case exactly. The > PlexusWagonProvider in Aether injects the PlexusContainer and when a Wagon > is requested it looks it up in the container. Down in the Plexus container > implementation in Sisu you will see the lookup/locate of a component is > constrained by the visible realms, and the TCCL contributes to create one > of these realms. So the one extension is not directly visible to the other > but classes of both are available in the context of a project. > > If it were a Map of wagons being injected I believe the same logic would > apply about the constraining by visible realms but Stuart knows exactly how > this is done (he implemented it), so might have something to add/correct. > > On May 21, 2014, at 4:33 AM, William Ferguson < > [email protected]> wrote: > > > Thanks Igor. That fixes it :-) > > > > Is there any fallout that I should be aware of from setting the > > Thread#contextClassloader to MaveProject#classReam at that point in the > > lifecycle? > > > > William > > > > > > On Wed, May 21, 2014 at 11:20 AM, Igor Fedorenko <[email protected] > >wrote: > > > >> MavenLifecycleParticipant comes from a build extension, so build > >> extensions are loaded for sure. > >> > >> Most likely the problem has to do with thread context classloader, you > >> need to set it to project extensions realm (as returned by > >> MavenProject.getClassRealm) to be able to lookup project build > >> extensions. And don't forget to restore TCCL in finally block ;-) > >> > >> -- > >> Regards, > >> Igor > >> > >> > >> On 2014-05-20, 20:27, William Ferguson wrote: > >> > >>> Hi Herve, > >>> > >>> I am using MLCP#afterProjectsRead. > >>> Unfortunately the extensions don't seem to be loaded at that point > either. > >>> > >>> William > >>> > >>> > >>> On Wed, May 21, 2014 at 10:03 AM, Hervé BOUTEMY <[email protected] > >>>> wrote: > >>> > >>> if you look at AbstractMavenLifecycleParticipant source file: > >>>> > >>>> /** > >>>> * Invoked after MavenSession instance has been created. > >>>> * > >>>> * This callback is intended to allow extensions to inject > execution > >>>> properties, > >>>> * activate profiles and perform similar tasks that affect > >>>> MavenProject > >>>> * instance construction. > >>>> */ > >>>> // TODO: This is too early for build extensions, so maybe just > >>>> remove > >>>> it? > >>>> public void afterSessionStart( MavenSession session ) > >>>> throws MavenExecutionException > >>>> { > >>>> > >>>> the TODO seems exactly what you're facing > >>>> > >>>> and if you have a look at place where it is used, ie > >>>> DefaultMaven.doExecute(...), you'll see that this method happens > really > >>>> too > >>>> early to be able to do anything about this problem > >>>> > >>>> IMHO, you'd better use afterProjectsRead(...) method, which should > have > >>>> the > >>>> right classloader prepared > >>>> > >>>> and we should probably change the "TODO" into javadoc, since this > shuld > >>>> be > >>>> documented limitation > >>>> > >>>> WDYT? > >>>> > >>>> Regards, > >>>> > >>>> Hervé > >>>> > >>>> Le lundi 19 mai 2014 11:31:42 William Ferguson a écrit : > >>>> > >>>>> So it boils down to ProjectDependenciesResolver being able to > resolve an > >>>>> s3wagon dependency from a Mojo, but not from > MavenLifecycleParticipant. > >>>>> > >>>>> Is it because RepositorySystem has not been fully configured by > >>>>> MLCP#afterProjectsRead? > >>>>> If so, is there a way to ensure that it is configured by then? > >>>>> > >>>>> Someone, anyone? > >>>>> > >>>>> William > >>>>> > >>>>> > >>>>> On Sun, May 18, 2014 at 9:23 AM, William Ferguson < > >>>>> > >>>>> [email protected]> wrote: > >>>>> > >>>>>> OK, I'm really hoping someone can provide some more insight on this > as > >>>>>> > >>>>> I > >>>> > >>>>> have reached my limit. > >>>>>> > >>>>>> To make things clearer, I have created a project containing > >>>>>> integration-tests showing the failure that is causing us grief > >>>>>> > >>>>> (external > >>>> > >>>>> wagon dependencies not being resolvable from within > >>>>>> MavenLifeCycleParticipant) and well as integration tests showing > that > >>>>>> > >>>>> that > >>>> > >>>>> same deps are resolvable either using the std Maven dep resolution or > >>>>>> explicit resolution from within a Mojo, > >>>>>> > >>>>>> https://github.com/william-ferguson-au/example-resolution-plugin. > >>>>>> > >>>>>> Could someone please have a look and help me work out how to get the > >>>>>> external wagon deps to resolve from the MLCP? > >>>>>> > >>>>>> William > >>>>>> > >>>>>> > >>>>>> On Fri, May 16, 2014 at 1:22 AM, William Ferguson < > >>>>>> > >>>>>> [email protected]> wrote: > >>>>>> > >>>>>>> No one on the user's list wanted to have a go at this. How about > >>>>>>> > >>>>>> someone > >>>> > >>>>> from the Dev list? > >>>>>>> > >>>>>>> William > >>>>>>> > >>>>>>> > >>>>>>> ---------- Forwarded message ---------- > >>>>>>> From: William Ferguson <[email protected]> > >>>>>>> Date: Mon, May 12, 2014 at 8:58 PM > >>>>>>> Subject: Wagon extensions not available from > >>>>>>> AbstractMavenLifecycleParticipant or maven-dependency-tree? > >>>>>>> To: Maven Users List <[email protected]> > >>>>>>> > >>>>>>> > >>>>>>> I have a MavenLifecycleParticipant in my plugin. It uses > >>>>>>> maven-dependency-tree to resolve some deps that we need to do extra > >>>>>>> processing on. It works fine if the deps are in the local repo. > >>>>>>> > >>>>>>> But if the s3 Wagon is defined in the project along with a > dependency > >>>>>>> from the s3 bucket, then the following debug log shows that > >>>>>>> DependencyGraphBuilder of maven-dependency-tree can't resolve the > s3 > >>>>>>> wagon, > >>>>>>> and the dependency is not resolved now or later in the build, so > >>>>>>> compilation fails. > >>>>>>> > >>>>>>> NB If I remove the MavenLifecycleParticipant then the dep is > resolved > >>>>>>> > >>>>>> via > >>>> > >>>>> the S3 Wagon. > >>>>>>> > >>>>>>> Q1) When are the Wagons configured? Shouldn't it be prior to > >>>>>>> MavenLifecycleParticipant being called? > >>>>>>> Q2) How can I get the DependencyGraphBuilder to resolve the s3 > >>>>>>> > >>>>>> artifact > >>>> > >>>>> from within the MavenLifecycleParticipant? > >>>>>>> > >>>>>>> > >>>>>>> Here is the stacktrace: > >>>>>>> > >>>>>>> [DEBUG] Could not find metadata > >>>>>>> > >>>>>>> com.viewpagerindicator:viewpagerindicator:2.4.2- > >>>> SNAPSHOT/maven-metadata.x > >>>> > >>>>> ml > >>>>>>> in local (D:\dev\maven-local-repository) > >>>>>>> [DEBUG] java.util.NoSuchElementException > >>>>>>> > >>>>>>> role: org.apache.maven.wagon.Wagon > >>>>>>> > >>>>>>> roleHint: s3 > >>>>>>> > >>>>>>> > >>>>>>> org.codehaus.plexus.component.repository.exception. > >>>> ComponentLookupExcepti > >>>> > >>>>> on: java.util.NoSuchElementException > >>>>>>> > >>>>>>> role: org.apache.maven.wagon.Wagon > >>>>>>> > >>>>>>> roleHint: s3 > >>>>>>> > >>>>>>> at > >>>>>>> > >>>>>>> org.codehaus.plexus.DefaultPlexusContainer.lookup( > >>>> DefaultPlexusContainer. > >>>> > >>>>> java:264)>> > >>>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> org.codehaus.plexus.DefaultPlexusContainer.lookup( > >>>> DefaultPlexusContainer. > >>>> > >>>>> java:252) at > >>>>>>> > >>>>>>> org.eclipse.aether.internal.connector.wagon. > >>>> PlexusWagonProvider.lookup(Pl > >>>> > >>>>> exusWagonProvider.java:33)>> > >>>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> org.eclipse.aether.connector.wagon.WagonRepositoryConnector. > >>>> lookupWagon(W > >>>> > >>>>> agonRepositoryConnector.java:337) at > >>>>>>> > >>>>>>> org.eclipse.aether.connector.wagon.WagonRepositoryConnector.< > >>>> init>(WagonR > >>>> > >>>>> epositoryConnector.java:157)>> > >>>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> org.eclipse.aether.connector.wagon.WagonRepositoryConnectorFactor > >>>> y.newIns > >>>> > >>>>> tance(WagonRepositoryConnectorFactory.java:159) at > >>>>>>> > >>>>>>> org.eclipse.aether.internal.impl.DefaultRepositoryConnectorProv > >>>> ider.newRe > >>>> > >>>>> positoryConnector(DefaultRepositoryConnectorProvider.java:139)>> > >>>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ > >>>> ResolveTask.run( > >>>> > >>>>> DefaultMetadataResolver.java:613) at > >>>>>>> > >>>>>>> org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run( > >>>> Runnable > >>>> > >>>>> ErrorForwarder.java:67)>> > >>>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ > >>>> 1.execute(Defaul > >>>> > >>>>> tMetadataResolver.java:540) at > >>>>>>> > >>>>>>> org.eclipse.aether.internal.impl.DefaultMetadataResolver. > >>>> resolve(DefaultM > >>>> > >>>>> etadataResolver.java:395)>> > >>>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> org.eclipse.aether.internal.impl.DefaultMetadataResolver. > >>>> resolveMetadata( > >>>> > >>>>> DefaultMetadataResolver.java:218) at > >>>>>>> > >>>>>>> org.apache.maven.repository.internal.DefaultVersionResolver. > >>>> resolveVersio > >>>> > >>>>> n(DefaultVersionResolver.java:250)>> > >>>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> org.apache.maven.repository.internal.DefaultArtifactDescriptorReade > >>>> r.load > >>>> > >>>>> Pom(DefaultArtifactDescriptorReader.java:284) at > >>>>>>> > >>>>>>> org.apache.maven.repository.internal.DefaultArtifactDescriptorReade > >>>> r.read > >>>> > >>>>> ArtifactDescriptor(DefaultArtifactDescriptorReader.java:217)>> > >>>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> org.eclipse.aether.internal.impl.DefaultDependencyCollector. > >>>> process(Defau > >>>> > >>>>> ltDependencyCollector.java:461) at > >>>>>>> > >>>>>>> org.eclipse.aether.internal.impl.DefaultDependencyCollector. > >>>> collectDepend > >>>> > >>>>> encies(DefaultDependencyCollector.java:261)>> > >>>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> org.eclipse.aether.internal.impl.DefaultRepositorySystem. > >>>> collectDependenc > >>>> > >>>>> ies(DefaultRepositorySystem.java:317) at > >>>>>>> > >>>>>>> org.apache.maven.project.DefaultProjectDependenciesReso > >>>> lver.resolve(Defau > >>>> > >>>>> ltProjectDependenciesResolver.java:159)>> > >>>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> org.apache.maven.shared.dependency.graph.internal. > >>>> Maven31DependencyGraphB > >>>> > >>>>> uilder.resolveDependencies(Maven31DependencyGraphBuilder.java:113) at > >>>>>>> > >>>>>>> org.apache.maven.shared.dependency.graph.internal. > >>>> Maven31DependencyGraphB > >>>> > >>>>> uilder.buildDependencyGraph(Maven31DependencyGraphBuilder.java:99)>> > >>>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> org.apache.maven.shared.dependency.graph.internal. > >>>> DefaultDependencyGraphB > >>>> > >>>>> uilder.buildDependencyGraph(DefaultDependencyGraphBuilder.java:74) at > >>>>>>> > >>>>>>> com.jayway.maven.plugins.android.common.DependencyResolver. > >>>> getProjectDepe > >>>> > >>>>> ndenciesFor(DependencyResolver.java:54)>> > >>>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> com.jayway.maven.plugins.android.phase_prebuild. > >>>> ClasspathModifierLifecycl > >>>> > >>>>> > >>>>>>> eParticipant.afterProjectsRead(ClasspathModifierLifecyclePart > >>>> icipant.java > >>>> > >>>>> :78) at > org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317) > >>>>>>> > >>>>>>> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155) > >>>>>>> > >>>>>>> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584) > >>>>>>> > >>>>>>> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213) > >>>>>>> > >>>>>>> at org.apache.maven.cli.MavenCli.main(MavenCli.java:157) > >>>>>>> > >>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > >>>>>>> > >>>>>>> at > >>>>>>> > >>>>>>> sun.reflect.NativeMethodAccessorImpl.invoke( > >>>> NativeMethodAccessorImpl.java > >>>> > >>>>> :57)>> > >>>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke( > >>>> DelegatingMethodAccessorI > >>>> > >>>>> mpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) > >>>>>>> > >>>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> org.codehaus.plexus.classworlds.launcher.Launcher. > >>>> launchEnhanced(Launcher > >>>> > >>>>> .java:289) at > >>>>>>> > >>>>>>> org.codehaus.plexus.classworlds.launcher.Launcher. > >>>> launch(Launcher.java:22 > >>>> > >>>>> 9) > >>>>>>> > >>>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> org.codehaus.plexus.classworlds.launcher.Launcher. > >>>> mainWithExitCode(Launch > >>>> > >>>>> er.java:415) at > >>>>>>> > >>>>>>> org.codehaus.plexus.classworlds.launcher.Launcher. > >>>> main(Launcher.java:356) > >>>> > >>>>> > >>>>>>> > >>>>>>> William > >>>>>>> > >>>>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [email protected] > >>>> For additional commands, e-mail: [email protected] > >>>> > >>>> > >>>> > >>> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > --------------------------------------------------------- > > A language that doesn’t affect the way you think about programming is not > worth knowing. > > -- Alan Perlis > > > > > > > > > >
