On Tue, May 7, 2013 at 1:27 AM, Adam Murdoch <adam.murd...@gradleware.com>wrote:
> > 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. > Having a metadata abstraction independent and eventually much richer than any particular dependency metadata format is in my opinion one of the most important building block for an improved promotion/release flow modeling in Gradle. I can't wait to see progress in this area and that this data can feed in into the resolution process. That we don't have this as a first class concept is one of my biggest pains at the moment. > 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. > Absolutely. Hans > > -- > 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 > >
