On 30/08/2013, at 7:38 AM, Adam Murdoch <adam.murd...@gradleware.com> wrote:
> > On 30/08/2013, at 6:39 AM, johnrengelman <john.r.engel...@gmail.com> 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
