Added a way to enable dynamic resolve for an Ivy repository. Does do anything yet.
Added some ignored int tests for ivy dynamic resolve mode.
Added ModuleVersionResolveResult.getMetaData() to allow the module version metadata to be exposed using our ModuleVersionDescriptor rather than Ivy's ModuleDescriptor.
Removed ModuleVersionResolveResult.getDescriptor().
Renamed ModuleVersionDescriptor to ModuleVersionMetaData.
Introduced DependencyMetaData, to be used as a replacement for Ivy's DependencyDescriptor when resolving. Made some changes to DependencyGraphBuilder to replace more usages of ModuleDescriptor and DependencyDescriptor with their Gradle equivalents.
Changed DependencyToModuleVersionIdResolver and DependencyToModuleResolver to use DependencyMetaData instead of Ivy DependencyDescriptor.
Changed ModuleVersionRepository and LocalAwareModuleVersionRepository to accept DependencyMetaData instead of DependencyDescriptor, and changed some more bits of DependencyGraphBuilder to use Gradle types instead of Ivy types.
REVIEW-1519: Don't use file-name, PublishArtifact.name or ArchiveTask.baseName as artifact name when publishing to ivy
- Default IvyArtifact.name to null, allowing it to inherit the published module name
- The plan is to decouple how things are generated in the build from how they are published
- Allowed multiple artifacts with same name in IvyDescriptor test code
REVIEW-1519: Create separate ivy configurations for artifacts and dependencies when publishing component
- jar/war artifact is in "master" configuration
- runtime deps are in "runtime" configuration
- "default" extends ["master", "runtime"]
- Added NamedDomainObjectContainer.maybeCreate(name)
REVIEW-1218: Removed magic parsing of filename when constructing publication artifact from file
- Only carry extension from file to published artifact: everything else will be configured explicitly.
REVIEW-1522, REVIEW-1544: Move classes and tests to better packages
REVIEW-1544: Simplified IvyDescriptorFileGenerator
Map Ivy configurations for component from details of component, rather than wiring logic in IvyPublication
- Added SoftwareComponent.getUsages() which returns a set of named Usage
- Each usage has a set of artifacts and dependencies
    - Dependencies are not yet mapped properly into ivy
    - Mapping of usage into Maven is very naive
Don't assume that all dependencies for a Usage are "runtime" in Ivy
- Added IvyDependency api and impl which wraps a ModuleDependency and conf mapping string
- Only currently used by components: user configuration of dependencies is not supported.
Changed UserResolverChain so that it passes up the module version meta-data without first unpacking and reassembling it. Changed BuildableModuleVersionMetaData to allow the dependency meta-data to be replaced (say, with revConstraint used instead of rev).
Introduced IvyAwareModuleVersionRepository to allow ivy settings to be attached to the repository (when it cares). Moved isLocal() to this interface from ModuleVersionRepository.
Added ConfigurationResolver which is used by DefaultConfiguration to resolve itself, to decouple DefaultConfiguration from all the infrastructure that is required to resolve it.
Moved a couple of classes from core -> coreImpl.
Added (internal) ResolutionAwareRepository, which represents a repository that knows how to resolve stuff and changed ArtifactDependencyResolver.resolve() to accept these as a parameter. Not used yet.