On 15/11/2012, at 3:35 AM, Luke Daley wrote: > > On 13/11/2012, at 10:43 PM, Adam Murdoch wrote: > >> >> On 13/11/2012, at 8:49 PM, Luke Daley wrote: >> >>> >>> On 13/11/2012, at 5:49 AM, Adam Murdoch wrote: >>> >>>> Hi, >>>> >>>> We have a bunch of issues queued up to fix in Gradle 1.4, all related to >>>> problems with using maven snapshots. For example, the source zips that the >>>> IDE project point to are not updated when a new snapshot is used. All of >>>> these are due to shortcomings in our implementation of changing modules. >>>> >>>> We have two basic approaches that we could take to fixing these: >>>> >>>> 1. Fix the issues with changing modules. >>>> 2. Switch to using dynamic versions for Maven snapshots. This will address >>>> the issues for Maven snapshots. We would then later fix the issues with >>>> changing modules. >>>> >>>> I'd like to go with option 2, as it is a better description of reality. It >>>> also allows us to make some nice performance improvements: >>>> * Don't download and parse maven-metadata.xml for every artefact download >>>> or up-to-date check. >>>> * Don't check if artefacts are up-to-date when maven-metadata.xml has not >>>> changed since last time we resolved. >>>> >>>> There are a bunch of other advantages to modelling Maven snapshots as >>>> dynamic versions. >>> >>> The distinction between “changing” and “dynamic” is confusing and non >>> obvious for users. It makes sense technically of course, but if we can >>> unify this concept I think we should for the sake of simplicity. >> >> Not sure it's necessarily a good idea to unify these things. >> >> Right now, we have a model something like this: >> >> * A repository contains a set of identifiable things. Currently we call >> these things 'module versions' but let's go a little more abstract and call >> them 'publications' here. >> >> * A publication has an identifier, a bunch of artefacts and some meta-data. >> >> * Some of these publications are uniquely versioned, and this version forms >> part of their identity. The meta-data and artefacts of these things never >> change [1]. >> >> * Some of these publications are not uniquely versioned, even though there >> is a 'version' attribute in their identity. Usually, the 'version' in this >> case refers to a stream of work. The meta-data and artefacts of these things >> can change. >> >> * A dependency declaration is a predicate for selecting a publication. We >> take the predicate and the contents of the repository and resolve this to a >> particular publication. That is, we map the predicate to a publication >> identifier. As a later step, we take the publication identifier and fetch >> the artefacts for the publication. >> >> We define a 'dynamic version' as a predicate that can map to different >> publication identifiers over time. A 'static version' is a predicate that >> always maps to the same publication identifier. >> >> We define a 'changing module' as a publication with a given identifier whose >> meta-data and artefacts can change over time. >> >> These are independent dimensions, so you can have a dynamic version that >> maps to a changing module, or a static version that maps to a changing >> module. >> >> >> [1] Given that the publications are almost always represented as binary >> files in a file store somewhere, this isn't entirely true. It's probably >> more accurate to say that they're unlikely to change. > > I should have been more specific, and provided much more context… > > As you rightly point out there are two things going on here, but there's an > overarching concept that I think we should unify what we currently have as > changing and dynamic under. > > The overarching concept, as far as the user is concerned is at least: > > 1. The notation I used to specify the dependency is “dynamic” in some way, so > Gradle needs to tell me how that was resolved > 2. How it is resolved can change over time, so the resolution should be > cacheable with a TTL > > At the moment, we don't have a term that encompasses what we call “dynamic” > and “changing”. This is awkward in the documenation and our APIs, as > evidenced by the different methods for the dynamic and changing TTLs. I don't > think there's any benefit in separate global TTLs for these two types of > things. It would be better to have one
We don't necessarily need to come up with a unifying concept to do this. We could add a `checkForChangesEvery` method, to serve as a default ttl for any cached information we have that is likely to change. I think 'check for changes' better describes what we're doing than 'cache for'. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
