Just issued Pull Request #187 - https://github.com/gradle/gradle/pull/187 Included tests for pom packaging, snapshots, non-unique snapshots, and normal artifacts.
-- John Engelman On Thursday, August 29, 2013 at 11:07 PM, John Engelman wrote: > Great. I have the resolver part worked out, just writing some tests around > it. Using the extra information in the ModuleVersionMetaData will be very > helpful. > > -- > John Engelman > > > On Thursday, August 29, 2013 at 11:05 PM, Adam Murdoch [via Gradle] wrote: > > > > > On 30/08/2013, at 7:38 AM, Adam Murdoch <[hidden email] > > (/user/SendEmail.jtp?type=node&node=5711777&i=0)> wrote: > > > > > > On 30/08/2013, at 6:39 AM, johnrengelman <[hidden email] > > > (/user/SendEmail.jtp?type=node&node=5711777&i=1)> wrote: > > > > I've gone back to the drawing board and came up with a simpler solution > > > > where > > > > in ExternalResourceResolver > > > > I check for any artifact existing and then only mark the artifact as > > > > resolved by that repository if one is found. > > > > > > We want to behave differently in this case for the Maven cache compared > > > to arbitrary repository. It's expected in the Maven cache for an artefact > > > to be missing, but it means a badly formed module everywhere else. > > > > > > I think we want something like this: > > > > > > 1. If we find a pom and no artifact in the Maven cache > > > * If we can find the module in some other repository, silently ignore the > > > stuff in the Maven cache and use the module from the other repository. > > > * If we cannot find the module in some other repository, fail with an > > > 'artefact missing' exception. > > > 2. If we find a pom and no artefact in some repository, fail with an > > > 'artefact missing' exception. > > > > > > Or, perhaps it might be nicer in #2 if we warn instead of fail when we > > > can find the module in another repository. > > > > > > Regardless of exactly what we do here, it's not the resolvers > > > responsibility to decide whether to fail or continue the search. Instead, > > > it should just communicate what it found, so that `UserResolverChain`, > > > which is coordinating the search, can take care of stopping or continuing > > > or whatever. To do this, we might add some new states to > > > `BuildableModuleVersionMetaDataResolveResult`, so that the resolver can > > > let the search algorithm know that it found a badly formed or partial > > > module. > > > > > > > > > > > > > > The problem I'm having is handling POM dependencies. There doesn't seem > > > > to > > > > be enough information passed in the Module Descriptor to know if the > > > > dependency that is currently being resolved has POM packaging. > > > > > > > > I tried one work around by looking at the ResolvedArtifact for the > > > > module > > > > descriptor and if it ends in ".pom" using the PomReader to parse it and > > > > get > > > > the packaging. That worked, but then I ran into issues with some > > > > integration > > > > tests where the the artifact packaging and classifiers didn't match > > > > (ArtifactDependenciesIntegrationTests.canUseClassifiersCombinedWithArtifactWithNonStandardPackaging). > > > > It appears that it was relying on the fact that the artifacts aren't > > > > checked > > > > before attempting resolution. > > > > > > I would change the `ModuleDescriptorParser` implementations to return a > > > `MutableModuleVersionMetaData` instead of `ModuleDescriptor` (this is the > > > plan anyway). > > > > I ended up making this change. So now we can add stuff to > > ModuleVersionMetaData to describe something about whether we expect the > > module to have artefacts or not. > > > > -- > > 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-tp5711584p5711777.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-tp5711584p5711780.html Sent from the gradle-dev mailing list archive at Nabble.com.
