I am absolutely certain that all project build extensions are loaded by
the time participant#afterProjectsRead is called, and this is the
callback used in William's example. Setting correct TCCL makes his
example work.

You are correct, however, that participant#afterSessionStart is invoked
before projects are read and their build extension realms are setup.
This callback is only useful for Maven core extensions deployed in
$M2_HOME/lib/ext and via -Dmaven.ext.class.path system property.

--
Regards,
Igor

On 2014-05-21, 2:41, Hervé BOUTEMY wrote:
no, extension are not loaded on this precise method: there is a TODO in the
interface about this, and when you read DefaultMaven, you see the reason why
this method can't have extensions = too early = the TODO comment

Regards,

Hervé

Le mardi 20 mai 2014 21:20:36 Igor Fedorenko a écrit :
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
<herve.bout...@free.fr>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 <

william.fergu...@xandar.com.au> 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 <

william.fergu...@xandar.com.au> 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 <william.fergu...@xandar.com.au>
Date: Mon, May 12, 2014 at 8:58 PM
Subject: Wagon extensions not available from
AbstractMavenLifecycleParticipant or maven-dependency-tree?
To: Maven Users List <us...@maven.apache.org>


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.WagonRepositoryConnectorFactory.newIns

tance(WagonRepositoryConnectorFactory.java:159) at

org.eclipse.aether.internal.impl.DefaultRepositoryConnectorProvider.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.DefaultArtifactDescriptorReader.load

Pom(DefaultArtifactDescriptorReader.java:284) at

org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.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.DefaultProjectDependenciesResolver.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(ClasspathModifierLifecycleParticipant.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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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


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


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

Reply via email to