[MJARSIGNER] verbose mode shows keystore password in clear text
Hi all guys, I'm using Maven Jar signer ver. 1.3.1 plugin and for security reasons I've encrypted the key store password with Maven encryption mechanism. All works fine, but if I enable verbose output, it print out the command line with the keystore password in clear text. here is an example: [INFO] cmd.exe /X /C C:\Program Files\Java\jdk1.7.0_51\jre\..\bin\jarsigner.exe -verbose -keystore mc-keystore -storepass mypassword is it possible to obfuscate the password? thanks a lot -- Marco Speranza marcospera...@apache.org http://code.google.com/u/marco.speranza79/
Re: [MJARSIGNER] verbose mode shows keystore password in clear text
On Wed, 5 Feb 2014 12:38:04 + Marco Speranza marcospera...@apache.org wrote: Hi all guys, hi Marco, I'm using Maven Jar signer ver. 1.3.1 plugin and for security reasons I've encrypted the key store password with Maven encryption mechanism. All works fine, but if I enable verbose output, it print out the command line with the keystore password in clear text. here is an example: [INFO] cmd.exe /X /C C:\Program Files\Java\jdk1.7.0_51\jre\..\bin\jarsigner.exe -verbose -keystore mc-keystore -storepass mypassword is it possible to obfuscate the password? Can you create the issue for this; I will have a look at it. thanks, tony. thanks a lot -- Marco Speranza marcospera...@apache.org http://code.google.com/u/marco.speranza79/ -- Tony Chemit tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: che...@codelutin.com twitter: https://twitter.com/tchemit - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MJARSIGNER] verbose mode shows keystore password in clear text
2014-02-05 Tony Chemit che...@codelutin.com: Can you create the issue for this; I will have a look at it. done: http://jira.codehaus.org/browse/MJARSIGNER-35 thanks a lot -- Marco Speranza marcospera...@apache.org Google Code: http://code.google.com/u/marco.speranza79/
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 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
Re: [ANN] Apache Maven SCM Publish Plugin 1.0 Released
On 4 February 2014 07:23, Hervé Boutemy hbout...@apache.org wrote: The Apache Maven team is pleased to announce the release of the Apache Maven SCM Publish Plugin, version 1.0 It looks as though the plugin now requires Maven 3, whereas 1.0-beta2 did not. Was that change intentional? If so, it ought to have been mentioned in the release notes (and on the website) The maven-scm-publish-plugin is a utility plugin to allow publishing Maven website to any supported SCM. The primary goal was to have an utility plugin to allow Apache projects to publish Maven websites via the ASF svnpubsub system. The plugin has been tested with git scm too and by example can push content for github pages. http://maven.apache.org/plugins/maven-scm-publish-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-scm-publish-plugin/artifactId version1.0/version /plugin Release Notes - maven-scm-publish-plugin - Version 1.0 ** Improvement * [MSCMPUB-6] - when creating a directory in svn, if checkout fails, wait a few seconds and retry * [MSCMPUB-7] - Add timestamp when commit starts (and ends) * [MSCMPUB-10] - Pick up SCM credentials from settings.xml server section * [MSCMPUB-11] - display content size (number of directories, files, and size) ** Story * [MSCMPUB-4] - Need a working example for GitHub/gh-pages, preferably naturally linked to natural site lifecycle, and multi-module ** Task * [MSCMPUB-3] - Upgrade to SCM-1.9 Enjoy, -The Apache Maven team - 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
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
Re: Plugins with parameters and defaultValue
Hi Baptiste, Hi, I think I remember a recent answer from Stephen about plugin conf, saying basically you'd just have to fall back to xpath project/build and then see what's present. First thanks for the hint... Any knowledge where to search for ? Or Stephen ? Do you have a hint ? Does exist an example within the apache maven plugins for such thing? Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: IOUtil.contentEqualsIgnoreEOL ?
Anyone? I suppose I have my answer, I'll leave the current patch as-is :-) 2014-01-28 Baptiste Mathus m...@batmat.net: Hi all, I created ARCHETYPE-456 yesterday for m-archetype-p to support comparing directories for integration-testing ignoring the EOL/newline encoding [1]. Currently, I put that code directory in the plugin. But I guess it'd better be placed alongside already existing IOUtil.contentEquals() method? I can create the associated JIRA and patch if seen as useful. But I'd like to check here before this wouldn't be seen as the wrong choice. This will prevent me from preparing a svn patch if this is gonna be rejected anyway :-). Btw, interestingly, this contentEqualsIgnoreEOL already exists in Apache commons-io [1]. Thanks Cheers [1] https://jira.codehaus.org/browse/ARCHETYPE-456 [2] http://commons.apache.org/proper/commons-io/apidocs/org/apache/commons/io/IOUtils.html#contentEqualsIgnoreEOL(java.io.Reader, java.io.Reader) -- Baptiste -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: Plugins with parameters and defaultValue
Here's the thread: http://maven.40175.n5.nabble.com/Maven2-Maven3-plugin-development-Ensuring-only-the-available-parameters-are-allowed-tp5780854p5780948.html Maybe I'd try something along those lines: Plugin plugin = lookupThePluginYouWant(project.getBuildPlugins()); Xpp3Dom config = (Xpp3Dom) plugin.getConfiguration(); // Unleash hell ? HTH 2014-02-05 Karl Heinz Marbaise khmarba...@gmx.de: Hi Baptiste, Hi, I think I remember a recent answer from Stephen about plugin conf, saying basically you'd just have to fall back to xpath project/build and then see what's present. First thanks for the hint... Any knowledge where to search for ? Or Stephen ? Do you have a hint ? Does exist an example within the apache maven plugins for such thing? Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;! dev-h...@maven.apache.org
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 i...@ifedorenko.com 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 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,
Re: IOUtil.contentEqualsIgnoreEOL ?
On 6 February 2014 06:45, Baptiste Mathus m...@batmat.net wrote: Anyone? I suppose I have my answer, I'll leave the current patch as-is :-) Isn't the long term plan to drop anything custom and use existing code? If its already in commons-io just use that instead. - 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
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(); ListMavenProject sortedProjects = projectDependencyGraph.getSortedProjects(); Kind regards Karl Heinz Marbaise On Wed, Feb 5, 2014 at 1:56 PM, Igor Fedorenko i...@ifedorenko.com 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 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
Re: IOUtil.contentEqualsIgnoreEOL ?
How about org.codehaus.plexus.util.StringUtils#unifyLineSeparators(String) ? We're already using plexus-utils, so that saves us another dependency :) Robert Op Wed, 05 Feb 2014 22:07:51 +0100 schreef Barrie Treloar baerr...@gmail.com: On 6 February 2014 06:45, Baptiste Mathus m...@batmat.net wrote: Anyone? I suppose I have my answer, I'll leave the current patch as-is :-) Isn't the long term plan to drop anything custom and use existing code? If its already in commons-io just use that instead. - 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 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 i...@ifedorenko.com 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) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver. resolveProjectDependencies(LifecycleDependencyResolver.java:127) at
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 mfriedenha...@gmail.com 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 i...@ifedorenko.com 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 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,
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
