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-tp5711584p5711778.html Sent from the gradle-dev mailing list archive at Nabble.com.
