On 2014-05-23, 19:45, William Ferguson wrote:
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?
Yes, this is expected. MavenProject.getClassRealm() returns project
extensions realm. If project does not have build extensions or plugin
elements with extensions=true, there is no extensions realm for the
project.
A correct LifeCycleParticipant implementation should always scope
component lookups to the current project's classloader and should use
the original classloader to allow lookup of the core components only.
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?
Each project has its own extensions realm. This avoids "leakage" of
enabled build extensions from one module to others and also allows
conflicting/incompatible extensions for different modules of a reactor
build. For example, it is entirely possible to have s3 wagon enabled for
one module and ssh wagon for another or have different versions of the
same extension enabled for different modules.
--
Regards,
Igor
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
