Daz - I just submitted the signed document to i...@gradleware.com Thanks!
-- John Engelman On Sunday, September 1, 2013 at 5:31 AM, Daz DeBoer-2 [via Gradle] wrote: > 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 <[hidden email] > (/user/SendEmail.jtp?type=node&node=5711787&i=0)> 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 (http://Nabble.com). > > > > If you reply to this email, your message will be added to the discussion > below: > http://gradle.1045684.n5.nabble.com/Maven-local-issues-tp5711584p5711787.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-tp5711584p5711789.html Sent from the gradle-dev mailing list archive at Nabble.com.
