The reason I'm delegating the snapshot behavior is because there is already additional checks for the snapshot timestamping and such. At first glance, I thought snapshot resolution would work ok, because the POM would be there but then it wouldn't find an artifact…I'll check to make sure.
Good point about the POM packing…I think maybe it would be better to look for the artifact that is being requested instead of just any artifact besides the POM. That should handle that situation then. If you configured a `maven()` repository to point at the m2 cache, then you could always provide a different 'artifactUrl' in its configuration to handle these issues. Though I think from a higher level, the question is, should this fall-through behavior be the default for all repositories? Even if it is a remote repository, if we find a POM but no artifact in any of the artifactUrls should we just hand off to the next repository instead of failing? -- John Engelman On Thursday, August 22, 2013 at 2:52 PM, Adam Murdoch [via Gradle] wrote: > > On 23/08/2013, at 2:47 AM, johnrengelman <[hidden email] > (/user/SendEmail.jtp?type=node&node=5711748&i=0)> wrote: > > 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? > > Thanks for tackling this bug. > > Your plan sounds good. I would probably get rid of step 4, as I don't think > there's any difference between a snapshot and a release as far as this bug > goes - it affects anything that may have come from a remote repository. > > I'd also probably do step 5 only if the packaging is not 'pom'. If we find a > pom whose packaging is 'pom', then we should probably use it. > > One question is what happens if I manually configure a `maven()` repository > to point at the m2 cache? Or, if I manually configure a `mavenLocal()` so > that it no longer points at the m2 cache? > > Possibly we want to decide whether to use the 'cache' (the new) or > 'repository' (the current) behaviour based on whether a repository points at > the m2 cache, regardless of how it ended up pointing there. > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > > Join us at the Gradle eXchange 2013, Oct 28th in London, UK: > http://skillsmatter.com/event/java-jee/gradle-exchange-2013 > > > > > If you reply to this email, your message will be added to the discussion > below: > http://gradle.1045684.n5.nabble.com/Maven-local-issues-tp5711584p5711748.html > > To start a new topic under gradle-dev, email > ml-node+s1045684n1436218...@n5.nabble.com > (mailto:ml-node+s1045684n1436218...@n5.nabble.com) > To unsubscribe from gradle-dev, click here > (http://gradle.1045684.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=1436218&code=am9obi5yLmVuZ2VsbWFuQGdtYWlsLmNvbXwxNDM2MjE4fDIyMTUyNjEzNQ==). > NAML > (http://gradle.1045684.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml) > -- View this message in context: http://gradle.1045684.n5.nabble.com/Maven-local-issues-tp5711584p5711749.html Sent from the gradle-dev mailing list archive at Nabble.com.
