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, and then be able to override at the dependency notation level. What I'm proposing is that we need a term/name that encompasses any kind of dependency request that is not “concrete” in terms of version, and talk about “dynamic” and “changing” as being different specialities of this. If we can deal with the backwards compatibility issues, I think the best thing to do would be to use the term “dynamic” and use a more specific term for what we currently call “dynamic”. It could be beneficial to separate the concept of version ranges and symbolics like "latest.integration”. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
