What scope do you use for these dependencies? I thought Maven allowed
folders for system-scoped dependencies, but I can be wrong. Maybe it is
possible to fake this by creating empty jar from the lifecycle
participant and then replace it with the real thing during the build.
My only other idea is to extend ArtifactHandler API to directly support
"AAR" usecase, i.e. when dependency is not added to classpath directly
but something is extracted from the dependency first and that extracted
file/directory is added to classpath instead.
--
Regards,
Igor
On 2/5/2014, 1:19, William Ferguson wrote:
Mmm I'm struggling to get the hack work.
The problem I am facing is that
1. the LifeCycleParticipant adds the location at which the Aar classes
are to be extracted to the classpath.
2. the Aar classes are extracted by the GenerateSourcesMojo to the
target folder
3. But (2) never happens because Maven throws a
LifeCycleExecutionException as soon as I execute a phase that requires
dependency resolution. It appears to do dep resolution prior to executing
any phases and it requires that the dependency physically exist. So it
throws an Exception because the Aar classes haven't been extracted yet.
Build output below.
Any ideas?
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO]
[INFO] AMLP afterProjectsRead
[INFO] AMLP afterProjectsRead
[INFO] AMLP afterProjectsRead
[INFO]
[INFO] CurrentProject=MavenProject:
com.jayway.maven.plugins.android.generation2.samples.libraryprojects:libraryprojects-aar-from-aar:1.0.0-SNAPSHOT
@
C:\OpenSource\maven-android-plugin-samples\libraryprojects\libraryprojects-aar-from-aar\pom.xml
[INFO]
[INFO]
project=com.jayway.maven.plugins.android.generation2.samples.libraryprojects:libraryprojects-aar-from-aar:aar:1.0.0-SNAPSHOT
[INFO] projects deps: :
[com.jayway.maven.plugins.android.generation2.samples.libraryprojects:libraryprojects-aar1:aar:1.0.0-SNAPSHOT:compile]
[INFO] Adding to classpath :
com.jayway.maven.plugins.android.generation2.samples.libraryprojects:libraryprojects-aar1:aar:1.0.0-SNAPSHOT:compile
[INFO] :
C:\OpenSource\maven-android-plugin-samples\libraryprojects\libraryprojects-aar-from-aar\target\unpacked-lib-classes\libraryprojects-aar1
[INFO]
[INFO]
------------------------------------------------------------------------
[INFO] Building Library Projects - AAR from AAR 1.0.0-SNAPSHOT
[INFO]
------------------------------------------------------------------------
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 1.797s
[INFO] Finished at: Wed Feb 05 15:45:41 EST 2014
[INFO] Final Memory: 9M/110M
[INFO]
------------------------------------------------------------------------
[ERROR] Failed to execute goal on project libraryprojects-aar-from-aar:
Could not resolve dependencies for project
com.jayway.maven.plugins.android.generation2.samples.libraryprojects:libraryprojects-aar-from-aar:aar:1.0.0-SNAPSHOT:
Could not find artifact
com.jayway.maven.plugins.android.generation2.samples.libraryprojects:libraryprojects-aar1:jar:1.0.0-SNAPSHOT
at specified path
C:\OpenSource\maven-android-plugin-samples\libraryprojects\libraryprojects-aar-from-aar\target\unpacked-lib-classes\libraryprojects-aar1
-> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal on project libraryprojects-aar-from-aar: Could not resolve
dependencies for project
com.jayway.maven.plugins.android.generation2.samples.libraryprojects:libraryprojects-aar-from-aar:aar:1.0.0-SNAPSHOT:
Could not find artifact
com.jayway.maven.plugins.android.generation2.samples.libraryprojects:libraryprojects-aar1:jar:1.0.0-SNAPSHOT
at specified path
C:\OpenSource\maven-android-plugin-samples\libraryprojects\libraryprojects-aar-from-aar\target\unpacked-lib-classes\libraryprojects-aar1
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:220)
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:127)
at
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:257)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:200)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.project.DependencyResolutionException: Could
not resolve dependencies for project
com.jayway.maven.plugins.android.generation2.samples.libraryprojects:libraryprojects-aar-from-aar:aar:1.0.0-SNAPSHOT:
Could not find artifact
com.jayway.maven.plugins.android.generation2.samples.libraryprojects:libraryprojects-aar1:jar:1.0.0-SNAPSHOT
at specified path
C:\OpenSource\maven-android-plugin-samples\libraryprojects\libraryprojects-aar-from-aar\target\unpacked-lib-classes\libraryprojects-aar1
at
org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:198)
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:195)
... 22 more
Caused by: org.eclipse.aether.resolution.DependencyResolutionException:
Could not find artifact
com.jayway.maven.plugins.android.generation2.samples.libraryprojects:libraryprojects-aar1:jar:1.0.0-SNAPSHOT
at specified path
C:\OpenSource\maven-android-plugin-samples\libraryprojects\libraryprojects-aar-from-aar\target\unpacked-lib-classes\libraryprojects-aar1
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:384)
at
org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:192)
... 23 more
Caused by: org.eclipse.aether.resolution.ArtifactResolutionException: Could
not find artifact
com.jayway.maven.plugins.android.generation2.samples.libraryprojects:libraryprojects-aar1:jar:1.0.0-SNAPSHOT
at specified path
C:\OpenSource\maven-android-plugin-samples\libraryprojects\libraryprojects-aar-from-aar\target\unpacked-lib-classes\libraryprojects-aar1
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:459)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:262)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:367)
... 24 more
Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Could not
find artifact
com.jayway.maven.plugins.android.generation2.samples.libraryprojects:libraryprojects-aar1:jar:1.0.0-SNAPSHOT
at specified path
C:\OpenSource\maven-android-plugin-samples\libraryprojects\libraryprojects-aar-from-aar\target\unpacked-lib-classes\libraryprojects-aar1
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:302)
... 26 more
William
On Wed, Feb 5, 2014 at 8:47 AM, William Ferguson <
william.fergu...@xandar.com.au> wrote:
Can you explain the need to establish the reactor build order? I had
expected session.getProjects() to have returned modules in the order they
are defined. Are you saying that is not the case and that it would need to
be configured by the LifeCycleParticipant?
I think I can make the hack work. So I'll go with that for now. But I'd
like to be able to annotate that with an issue number if there are plans to
enhance the API on this front so that we know what and when to replace.
I'd love to help enhance Maven (I have plenty to pay back for the hours it
has saved me over the years) but I don't have the band width right now and
I also don't feel like I have a good enough understanding of the Maven
core. But as I said before if you think this is a worthwhile enterprise
then help me create an issue that spells out what you think needs doing and
I'll try to get back to it in a couple of months.
William
On Tue, Feb 4, 2014 at 10:39 PM, Igor Fedorenko <i...@ifedorenko.com>wrote:
On 2/4/2014, 1:06, William Ferguson wrote:
OK, I'm getting the dependencies to resolve and I can amend the
classpath,
but I think I've hit a road block for multi module builds.
LifeCycleParticipant is only ever called once at the root. This means
that
if I have a project with 2 modules where ModuleB depends on ModuleA then
I'm not going to be able extract and add ModuleA and it's classes when
the
LifeCycleParticipant executes because ModuleA will not have been built
yet.
Is there some way to get the LifeCycleParticipant called for every module
of the build?
Looks like there are two related but distinct concerns there.
First, it is necessary to establish reactor build order. This must
happen before actual build starts and lifecycle participant provides a
way to do this.
Second, it is necessary to resolve dependencies among reactor modules.
This has to happen as part of the build itself and I don't think there
is an API for that yet.
One hack-ish way to workaround this is to resolve reactor dependencies
is to create empty directories from lifecycle participant,
ModuleA/target/something in your case, and make sure ModuleA's build
populates the directory with expected files.
Proper solution requires changes to maven core. I can provide some
pointers if you want to try this.
--
Regards,
Igor
William
William
On Tue, Feb 4, 2014 at 12:46 PM, William Ferguson <
william.fergu...@xandar.com.au> wrote:
Igor,
I've worked out how to modify the project classpath (pretty trivial).
But
I'm struggling to get the project dependencies resolved during
LifeCycleParticipant#afterProjectsRead.
I tried using the TychoDependencyResolver to #setupProject and
#resolveProject but that isn't causing the projects dependencies to get
resolved. I'm not sure what I'm missing.
I've created a cut down project dep-resolution-plugin at
https://github.com/william-ferguson-au/dep-resolution-plugin.git
And a project that tests that plugin at
https://github.com/william-ferguson-au/dep-resolution-plugin-test.git
If you could have a look and point out what it is I'm missing I'd be
most
grateful.
William
On Sat, Jan 25, 2014 at 6:57 AM, William Ferguson <
william.fergu...@xandar.com.au> wrote:
Maven 3.1.1 official, and all the plugin dependencies are 3.,1.1 too.
I'll trying switching to the annotations. Javadoc annotations were just
for conformity with the rest of the project.
If that doesn't work, I'll put together a cut down example.
Thanks.
William
On Thu, Jan 23, 2014 at 9:43 PM, Igor Fedorenko <i...@ifedorenko.com
wrote:
No, no tricks, as far as I know Plexus (and now Sisu/Guice) only
inject
fully configured components. so the behaviour you describe is rather
odd.
What version of Maven do you use? Is it official distribution from
Apache or something you built locally?
Not likely related, but I haven't used javadoc plexus annotations in
ages. Any particular reason you don't want to use java 5 @Component?
In any case, if you can provide small standalone example that shows
the
problem, I can try to see what's going on there.
--
Regards,
Igor
On 1/23/2014, 0:54, William Ferguson wrote:
Igor,
I'm having some difficulty getting the LifecycleParticipant to
resolve
Maven components.
In particular, the org.apache.maven.project.
ProjectDependenciesResolver.
While it gets resolved, none of it's internal attributes get
resolved.
So
calls to projectDependenciesResolver.resolve crash with NPEs because
DefaultProjectDependenciesResolver#logger or #repoSystem is not
initialised.
/**
* @component
* @readonly
* @required
*/
protected ProjectDependenciesResolver
projectDependenciesResolver;
Is there some special trick to getting components fully initialised
in a
LifecycleParticipant?
William
On Tue, Jan 21, 2014 at 12:21 AM, Igor Fedorenko <
i...@ifedorenko.com
wrote:
Here is Tycho lifecycle participant [1] and here is the code that
injects new dependencies in MavenProject instances [2].
[1] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/
tree/tycho-core/src/main/java/org/eclipse/tycho/core/maven/
TychoMavenLifecycleParticipant.java?h=tycho-0.19.x
[2] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/
tree/tycho-core/src/main/java/org/eclipse/tycho/core/maven/
MavenDependencyInjector.java?h=tycho-0.19.x
--
Regards,
Igor
On 1/20/2014, 8:21, William Ferguson wrote:
Thanks Igor,
could you give me a link to an example or some code that
- Utilises AbstractMavenLifecycleParticip
ant#afterProjectsRead
- How to manipulate the project <dependencies> from there.
I found an example example by Brett Porter, but the doco is pretty
thin
and
I can't see how I would go about inject extra elements into the
classpath
from there.
William
On Mon, Jan 20, 2014 at 10:47 PM, Igor Fedorenko <
i...@ifedorenko.com
wrote:
There is probably more ways to do this, but you can implement
AbstractMavenLifecycleParticipant#afterProjectsRead to manipulate
project <dependencies>. This is what we do in Tycho, where we
resolve
project OSGi dependencies in AbstractMavenLifecycleParticipant
and
then
inject that into Maven project model as system scoped maven
dependencies.
I also think your usecase highlights general deficiency with
current
dependency model. Since you have to add classpath elements
dynamically,
these elements are not visible to maven-based tools like m2e
without
additional effort on the tools part. I think it will be useful to
extend
<dependency> element syntax to allow references for nested
archive entries, i.e. "dependency on classes jar nested within
this
AAR
archive".
--
Regards,
Igor
On 1/20/2014, 7:00, William Ferguson wrote:
Hi,
I realise this question isn't exactly related to dev within the
Maven
components, but it is about developing a Mojo using components
that
have
to
be pretty central and don't appear to be obviously documented
anywhere.
And
I ahve asked on maven-users without much luck.
As part of the android-maven-plugin we have a Mojo which needs to
add an
element to the compile time classpath for future Mojos
(specifically the
maven-compiler-plugin).
Project has dependencies on artifacts of type AAR (Android
archive
- an
archive that contains several sub-artifacts including a classes
jar).
Our Mojo unpacks the AAR artifacts and makes the sub-artifacts
available
to
other build components.
One of those build components is the maven-compiler-plugin. We
want
to
add
the classes contained in the AAR dependencies to the compile
classpath
so
that the maven-compiler-plugin can compile our classes against
the
classes
from the AARs.
How do we do that?
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
