Hi Robert, I found an "unexpected exception feature" ;)
I have tested consumer on a GWT project and get this exception:> Caused by: java.lang.IllegalStateException: Duplicate dependency! Original: net.sf.m-m-m:mmm-util-core:jar:sources:sources duplicate: net.sf.m-m-m:mmm-util-core:jar:sources:sources > at org.codehaus.mojo.consumer.Dependencies.add(Dependencies.java:84)
> Artifact artifact = this.project.getArtifactMap().get( artifactKey );
> if ( artifact != null ) > consumerDependency = new Dependency(); > consumerDependency.setGroupId( artifact.getGroupId() ); > consumerDependency.setArtifactId( artifact.getArtifactId() ); > consumerDependency.setVersion( artifact.getVersion() ); > consumerDependency.setScope( artifact.getScope() ); > consumerDependency.setType( artifact.getType() ); > consumerDependency.setClassifier( artifact.getClassifier() ); > consumerDependency.setOptional( artifact.isOptional() );> // for completeness, actually system scope is sick for consumers > consumerDependency.setSystemPath( projectDependency.getSystemPath() ); > consumerDependency.setExclusions( projectDependency.getExclusions() ); what was the reason for this change rather than copying the projectDependency to the consumerDependency? This code is causing problems with a "duplicate" dependency without classifier and one with classifier as typically used in GWT projects. Maybe I am also missing the point for the problem, but I think this code can not work in such case as the artifactKey is the same for both dependencies.
I have no idea why we need the artifactMap indirection at all. To reveal the problem I have added an IT casing the exception. Kind regards Jörg Am 01.03.2014 21:16, schrieb Robert Scholte:
Hi Jörg,it seems like the DefaultProfileInjector is the class which blocks our solutions. After some digging I found that by tuning the ModelBuilder we get the resolution as done by Maven AND have to correct interpolation.Current code is still a bit dirty, but should show they way to go. RobertOp Sat, 01 Mar 2014 00:02:27 +0100 schreef Robert Scholte <codeh...@sourcegrounds.com>:Hi Jörg,let's both keep searching for those edge cases to see if the Interpolator is the correct solution if in fact the MavenProject does contain all the required information (maybe a bit deeper then expected probably).I'll add IT's for the groupId and artifactId with expressions.About the release process: you can't release from the sandbox, you need to call for a vote first to get it out of the sandbox. Mojo doesn't use the 0.9.0, but 1.0-alphas or -betas, see http://mojo.codehaus.org/development/process.htmlRobertOp Fri, 28 Feb 2014 23:48:36 +0100 schreef Jörg Hohwiller <jo...@j-hohwiller.de>:Am 27.02.2014 22:12, schrieb Robert Scholte:Hi Jörg,Hi Robert,I think I found the solution without the Interpolator. I've written several IT's to confirm this. If there's a case which isn't coeverd, let me know.There are cases where your approach does not work. You can also use variables in groupId and artifactId.The only solid and valid approach is using Interpolator. I managed to dothis in parallel to your changes and have committed this change. I willneed to add more ITs but wont have time before next week. Further I willupdate the documentation to have a proper explanation why and how this plugin can/should be used. Besides awaiting feedback, I am then very prepared to go for an initial release (0.9.0).First svn needs to be up again before I can commit.Ok. So this was not a problem at my end. Also Jira.codehaus.org DNS entry is gone and I have no way to access JIRA anymore. There are various issues that can be solved with consumer-maven-plugin such as MNG-624 and many others. You can simply stop changing the versions of your parent POMs (the aggregation POMs that declare the modules). Then you can use variables and dependencyManagement centrally defined in your toplevel POM and you have final freedom. This is what I was looking for since over two years. What a relieve!RobertThanks for your support so far - you should also add yourself as developer in the pom of the plugin :) JörgOp Thu, 27 Feb 2014 20:44:40 +0100 schreef Jörg Hohwiller <jo...@j-hohwiller.de>:Hi Robert, Am 27.02.2014 18:54, schrieb Robert Scholte:"But I had to do this because otherwise I would also get the profile triggered dependencies and can not figure out their origin to filter them." Which method were you using?Initially MavenProject.getDependencies()then MavenProject.getOriginalModel().getDependencies() (recursively viaMavenProject.getParent()).I had all this manually tested. E.g. net.sf.m-m-m:mmm-util-core is oneI'll add an IT for this and see if it is really required.of my use-cases.It shouldn't be required to use the ModelInterpolator.I could also use a regular Interpolator and configure it manually. However, I would like to reuse as much as original logic of maven aspossible. If I start parsing Strings and looking for ${...} I will endup in a maintenance hell. As long as I am waiting for some core Maven coder for hints to my problem, I can try instantiating StringSearchInterpolator as I assume this is the core logic used to do the interpolation. Any hints would help for my enlightenment...RobertRegards JörgOp Thu, 27 Feb 2014 00:51:43 +0100 schreef Jörg Hohwiller <jo...@j-hohwiller.de>:Hi there, I need help from a real maven expert - see below... Am 26.02.2014 23:51, schrieb Jörg Hohwiller:Am 26.02.2014 21:08, schrieb Robert Scholte: [...]The resolve-properties now exposes a small issue: the property is not resolved. I hope you can fix that.Sure. That is coming from the fact that I now take them from the originalModel instead of the MavenProject itself. But I had to do thisbecause otherwise I would also get the profile triggered dependenciesand can not figure out their origin to filter them. I will try to fix this. I think it is easier to re-interpolate theproperties using the MavenProject than trying to match which of the MavenProject dependencies match to which un-interpolated dependency. If anybody has a hint for some magic function in Maven that alreadydoes this job so I can reuse it and get the exact same feature, please let me know...I added this: @Component private ModelInterpolator interpolator; and this: ... try {this.interpolator.interpolate(model, this.project.getBasedir(),this.project.getProjectBuilderConfiguration(), getLog().isDebugEnabled()); } catch (ModelInterpolationException e) { throw new MojoExecutionException("Interpolation failed", e); } return model; } what I get is this: org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:consumer-maven-plugin:0.9.0-SNAPSHOT:consumer(default-cli) on project resolve-properties: Execution default-cli of goal org.codehaus.mojo:consumer-maven-plugin:0.9.0-SNAPSHOT:consumerfailed: An API incompatibility was encountered while executing org.codehaus.mojo:consumer-maven-plugin:0.9.0-SNAPSHOT:consumer: java.lang.NoSuchMethodError:org.apache.maven.project.MavenProject.getProjectBuilderConfiguration()Lorg/apache/maven/project/ProjectBuilderConfiguration;Seems like to much classloader and shading magic is going on for my poor understanding of maven internals. Any help is very much appreciated. Thanks Jörg---------------------------------------------------------------------To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email--------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email--------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email--------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
smime.p7s
Description: S/MIME Cryptographic Signature
