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
Possibly. You've really just described dependency resolution here. Every dependency declaration has the potential to have some kind of dynamic result, and you can't necessarily look at the notation and know that the result is always going to be the same. Some notations you can look at and know that the result is likely to change (but may not) and some notations you can look at and know that the result is unlikely to change (but may). And some you have no idea. Still, it might be useful to have a term for dependencies that are likely to resolve to different artefacts over time. What would the definition of such as thing be? It can't be that it's "dynamic" in some way because every dependency declaration is dynamic. It needs to be more specific. > > 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. It's only awkward if there is actually a single concept here. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
