Re: Adding a classpath element within a Mojo
Hi Igor, one other thing to mention is that the Java resources contained in classes.jar need to be extracted into a folder and made available to aapt when it is constructing an APK. So ideas on how we should properly deal with this requirement using an ArtrifactHandler or other mechanism? William On Fri, Feb 7, 2014 at 1:58 PM, William Ferguson < william.fergu...@xandar.com.au> wrote: > :-) well unless you are doing Android dev there really isn't any need to > know what the AAR structure is. > > An AAR contains the following: > >- assets folder - Contains any number of text or binary assets. >- res folder - Contains zero or more other folders which contains text >or binary resources for different densities/sizes and views. >- AndroidManifest.xml which defines the application >- classes.jar (what all the fuss has been about) >- R.txt text file declaring the resources from the res folder with a >unique identifier for each. > > All of the resources are consumed by the aapt application to generate an > APK (Android application package file) which contains a dex file (byte code > representation) plus the resources (assets, res, AndroidManifest.xml). > > We need to make several passes with aapt to generate several intermediate > artefacts before finally generating the APK. > > So at the moment extracting the AAR works well, as long as we can add > classes.jar to the classpath. > > > > > On Thu, Feb 6, 2014 at 2:50 PM, Igor Fedorenko wrote: > >> I don't have all the answers, but I think it is relatively common to >> have dependency on something available inside an archive deployed to a >> repository and I am interested to figure out how to express such >> dependencies in maven. >> >> First, however, I need to apologize for my ignorance about Android >> development (really have no excuse here) and ask for more info about use >> of AAR during the build. Does the build need any other AAR entries or >> classes.jar is the only entry needed by the build? >> >> -- >> Regards, >> Igor >> >> >> >> On 2/5/2014, 20:56, William Ferguson wrote: >> >>> Wrt to the ArtifactHandler for AAR artifacts. Could you expand on that. >>> Would this be the correct approach to handling artifacts that potentially >>> contain other artifacts/resources? Where should I start in going down >>> this >>> path? >>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> >
Re: Adding a classpath element within a Mojo
:-) well unless you are doing Android dev there really isn't any need to know what the AAR structure is. An AAR contains the following: - assets folder - Contains any number of text or binary assets. - res folder - Contains zero or more other folders which contains text or binary resources for different densities/sizes and views. - AndroidManifest.xml which defines the application - classes.jar (what all the fuss has been about) - R.txt text file declaring the resources from the res folder with a unique identifier for each. All of the resources are consumed by the aapt application to generate an APK (Android application package file) which contains a dex file (byte code representation) plus the resources (assets, res, AndroidManifest.xml). We need to make several passes with aapt to generate several intermediate artefacts before finally generating the APK. So at the moment extracting the AAR works well, as long as we can add classes.jar to the classpath. On Thu, Feb 6, 2014 at 2:50 PM, Igor Fedorenko wrote: > I don't have all the answers, but I think it is relatively common to > have dependency on something available inside an archive deployed to a > repository and I am interested to figure out how to express such > dependencies in maven. > > First, however, I need to apologize for my ignorance about Android > development (really have no excuse here) and ask for more info about use > of AAR during the build. Does the build need any other AAR entries or > classes.jar is the only entry needed by the build? > > -- > Regards, > Igor > > > > On 2/5/2014, 20:56, William Ferguson wrote: > >> Wrt to the ArtifactHandler for AAR artifacts. Could you expand on that. >> Would this be the correct approach to handling artifacts that potentially >> contain other artifacts/resources? Where should I start in going down this >> path? >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Adding a classpath element within a Mojo
I don't have all the answers, but I think it is relatively common to have dependency on something available inside an archive deployed to a repository and I am interested to figure out how to express such dependencies in maven. First, however, I need to apologize for my ignorance about Android development (really have no excuse here) and ask for more info about use of AAR during the build. Does the build need any other AAR entries or classes.jar is the only entry needed by the build? -- Regards, Igor On 2/5/2014, 20:56, William Ferguson wrote: Wrt to the ArtifactHandler for AAR artifacts. Could you expand on that. Would this be the correct approach to handling artifacts that potentially contain other artifacts/resources? Where should I start in going down this path? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: reactorProjects vs. session.getProjects() Was: Re: Adding a classpath element within a Mojo
Yes. On Feb 5, 2014, at 4:05 PM, Mirko Friedenhagen wrote: > Hello, > > just for my understanding: > - Does the property reactorProjects[0] hold the projects in reactor build > order? > > Regards Mirko > [0] > https://github.com/apache/maven-plugins/blob/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/InstallMojo.java#L68 > > On Wed, Feb 5, 2014 at 1:56 PM, Igor Fedorenko wrote: >> Maven first calls #afterProjectsRead(MavenSession), then calculates >> reactor build order. So session.getProjects() still returns unsorted >> project list during afterProjectsRead, which most likely does not matter >> in your case. >> >> -- >> Regards, >> Igor >> >> >> On 2/4/2014, 17:47, William Ferguson 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 >>> 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 >>> wrote: >>> >>> >>> No, n
Re: Adding a classpath element within a Mojo
Thanks very much for your help with this Igor. Providing a dummy classes.jar was enough to get everything up and running. But it really does feel like a hack. The hack is going to buy us some time, but I'd like to construct a proper solution (if such a thing exists). Wrt to the ArtifactHandler for AAR artifacts. Could you expand on that. Would this be the correct approach to handling artifacts that potentially contain other artifacts/resources? Where should I start in going down this path? William On Wed, Feb 5, 2014 at 11:11 PM, Igor Fedorenko wrote: > 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) >>
Re: reactorProjects vs. session.getProjects() Was: Re: Adding a classpath element within a Mojo
Hi Mirko, > just for my understanding: - Does the property reactorProjects[0] hold the projects in reactor build order? Regards Mirko [0] https://github.com/apache/maven-plugins/blob/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/InstallMojo.java#L68 As far as i know the following gives you the correct order: ProjectDependencyGraph projectDependencyGraph = mavenSession.getProjectDependencyGraph(); List sortedProjects = projectDependencyGraph.getSortedProjects(); Kind regards Karl Heinz Marbaise On Wed, Feb 5, 2014 at 1:56 PM, Igor Fedorenko wrote: Maven first calls #afterProjectsRead(MavenSession), then calculates reactor build order. So session.getProjects() still returns unsorted project list during afterProjectsRead, which most likely does not matter in your case. -- Regards, Igor On 2/4/2014, 17:47, William Ferguson 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 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 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 Fergu
reactorProjects vs. session.getProjects() Was: Re: Adding a classpath element within a Mojo
Hello, just for my understanding: - Does the property reactorProjects[0] hold the projects in reactor build order? Regards Mirko [0] https://github.com/apache/maven-plugins/blob/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/InstallMojo.java#L68 On Wed, Feb 5, 2014 at 1:56 PM, Igor Fedorenko wrote: > Maven first calls #afterProjectsRead(MavenSession), then calculates > reactor build order. So session.getProjects() still returns unsorted > project list during afterProjectsRead, which most likely does not matter > in your case. > > -- > Regards, > Igor > > > On 2/4/2014, 17:47, William Ferguson 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 >> 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 >> >>> 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 >>> Ap
Re: Adding a classpath element within a Mojo
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.jav
Re: Adding a classpath element within a Mojo
Maven first calls #afterProjectsRead(MavenSession), then calculates reactor build order. So session.getProjects() still returns unsorted project list during afterProjectsRead, which most likely does not matter in your case. -- Regards, Igor On 2/4/2014, 17:47, William Ferguson 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 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 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 f
Re: Adding a classpath element within a Mojo
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.codeha
Re: Adding a classpath element within a Mojo
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 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 >>> >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 >>* @re
Re: Adding a classpath element within a Mojo
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 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 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 AbstractMavenLifecycleParticipant#afterProjectsRead - How to manipulate the project 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 wrote: There is probably more ways to do this, but you can implement AbstractMavenLifecycleParticipant#afterProjectsRead to manipulate project . This is what we do in Tycho, where we resolve project OSGi dependencie
Re: Adding a classpath element within a Mojo
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? 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 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 >>> >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 AbstractMavenLifecycleParticipant#afterProjectsRead >> - How to manipulate the project 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 > >>> wrote: >>> >> >> There is probably more ways to do this, but you can implement >> >>> AbstractMavenLifecycleParticipant#afterProjectsRead to manipulate >>> project . 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
Re: Adding a classpath element within a Mojo
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 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 >> >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 AbstractMavenLifecycleParticipant#afterProjectsRead > - How to manipulate the project 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 >> wrote: >> > > There is probably more ways to do this, but you can implement > >> AbstractMavenLifecycleParticipant#afterProjectsRead to manipulate >> project . 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 >> 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. >
Re: Adding a classpath element within a Mojo
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 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 > >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 AbstractMavenLifecycleParticipant#afterProjectsRead - How to manipulate the project 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 >>> > wrote: > There is probably more ways to do this, but you can implement > AbstractMavenLifecycleParticipant#afterProjectsRead to manipulate > project . 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 > 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 >>
Re: Adding a classpath element within a Mojo
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 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 AbstractMavenLifecycleParticipant#afterProjectsRead - How to manipulate the project 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 wrote: There is probably more ways to do this, but you can implement AbstractMavenLifecycleParticipant#afterProjectsRead to manipulate project . 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 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
Re: Adding a classpath element within a Mojo
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 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 AbstractMavenLifecycleParticipant#afterProjectsRead >> - How to manipulate the project 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 > >wrote: >> >> There is probably more ways to do this, but you can implement >>> AbstractMavenLifecycleParticipant#afterProjectsRead to manipulate >>> project . 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 >>> 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 > >
Re: Adding a classpath element within a Mojo
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 AbstractMavenLifecycleParticipant#afterProjectsRead - How to manipulate the project 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 wrote: There is probably more ways to do this, but you can implement AbstractMavenLifecycleParticipant#afterProjectsRead to manipulate project . 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 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
Re: Adding a classpath element within a Mojo
Thanks Igor, could you give me a link to an example or some code that - Utilises AbstractMavenLifecycleParticipant#afterProjectsRead - How to manipulate the project 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 wrote: > There is probably more ways to do this, but you can implement > AbstractMavenLifecycleParticipant#afterProjectsRead to manipulate > project . 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 > 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 > >
Re: Adding a classpath element within a Mojo
There is probably more ways to do this, but you can implement AbstractMavenLifecycleParticipant#afterProjectsRead to manipulate project . 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 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
