On 06/05/2013, at 7:16 PM, Daz DeBoer <darrell.deb...@gradleware.com> wrote:
> On 3 May 2013 03:08, Peter Niederwieser <pnied...@gmail.com> wrote: > Devs, > > I've published a first version of the "custom Ivy status schemes" design > spec here: > https://github.com/gradle/gradle/blob/master/design-docs/custom-ivy-status.md > > If you are interested in reviewing the spec, please do so as soon as > possible. My goal is to start on the implementation early next week. > > It looks like we are reinforcing 'status' and 'statusScheme' as a standard > piece of metadata that _all_ modules support. Is this what we want? Sure. Every module has a lifecycle, regardless of where and how it is published, and this is the first step in capturing it. It will evolve into something richer than a 'status' string at some point. > How do these concepts map to a maven repository, or a flatdir repository? The meta-data formats that these repository types don't say anything about the lifecycle. But neither does all meta-data in an Ivy repository (e.g. it may not be specified in the ivy.xml, or there may be no ivy.xml). So, the question is what do we do when asked to select a version based on its lifecycle and the meta-data for that version does not say anything about lifecycle. Some options: 1. This meta-data can be defined somewhere else, such as a rule in the consumer, or a Gradle-specific meta-data file, or some web service. 2. We map whatever the meta-data files do tell us to a lifecycle. For example, we might use the <release> element in maven-metadata.xml to decide if a given version is a release or milestone or something else. 3. Default to the least mature status. This is what we do now. 4. Fail the resolution. Of course, you can combine these. > > Or should we be looking at introducing separate ivy/maven module apis, like > we have for publishing? > > Something like: > moduleMetadata.withType(IvyModule) { module -> > module.statusScheme = ['gold', 'silver', 'bronze'] > } We'll probably end up with something like this too. The role of the consumer-side meta-data rule is to take the meta-data from the repository and map it to the Gradle model, which then feeds into the dependency resolution algorithm. Some of those rules are going to need to use repository format-specific meta-data to do this mapping. -- 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 Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com
