I've started looking at a fix for GRADLE-2034 <http://issues.gradle.org/browse/GRADLE-2034> with respect to mavenLocal() having artifact POMs but not the corresponding artifact. It appears the Maven does this a lot. I've been seeing it anytime I execute a 'mvn install' on the same machine that I run Gradle builds on (totally prevents our CI server being used for both Maven and Gradle).
This is my plan to fix: 1) Create a new 'DefaultMavenLocalArtifactRespository' extending from 'DefaultMavenArtifactRespository' 2) Override the 'createRealResolver' method to return a new 'MavenLocalResolver' class 3) 'MavenLocalResolver' extends 'MavenResolver' and overrides the 'getDependency' method. 4) 'MavenLocalResolve.getDependency' delegates to 'MavenResolver' for snapshot behavior, otherwise.. 5) Implement a new method 'resolveIfArtifactPresent' that upon 'ivyRef != null', it calls the 'findAnyArtifact' method in 'ExternalResourceResolver' and only resolves the artifact if the return is non-null I've implemented this fix locally and it appears to the solve the issue and allow the mavenLocal resolve to fail-over to the next repository when it finds a POM but no artifact. I'm implement some tests around these scenarios now...I suspect a bunch of integration tests will break because they create a Pom file test test resolution but not an artifact. Does this sound like a good plan for fixing the bug? Is there a better design that is being thought of? I'm going to have some time in the next week or so and I'd like to get this and the publish to mavenLocal bug ( GRADLE-2762 <http://issues.gradle.org/browse/GRADLE-2762> ) fixed. Thanks! John Engelman -- View this message in context: http://gradle.1045684.n5.nabble.com/Maven-local-issues-tp5711584p5711747.html Sent from the gradle-dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
