Hi John I can't see a record of you submitting a signed CLA: if you haven't done so can you please submit as per https://github.com/gradle/gradle/blob/master/CONTRIBUTING.md. If you have done so, just let us know and we'll follow up on it.
Thanks Daz On Fri, Aug 30, 2013 at 4:26 PM, johnrengelman <john.r.engel...@gmail.com>wrote: > 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]<http://user/SendEmail.jtp?type=node&node=5711777&i=0>> > wrote: > > > On 30/08/2013, at 6:39 AM, johnrengelman <[hidden > email]<http://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 [hidden > email]<http://user/SendEmail.jtp?type=node&node=5711780&i=0> > To unsubscribe from gradle-dev, click here. > 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: Re: Maven local > issues.<http://gradle.1045684.n5.nabble.com/Maven-local-issues-tp5711584p5711780.html> > > Sent from the gradle-dev mailing list > archive<http://gradle.1045684.n5.nabble.com/gradle-dev-f1436218.html>at > Nabble.com. >
