On Wed, Nov 14, 2012 at 6:36 AM, Adam Murdoch <[email protected]>wrote:
> > On 14/11/2012, at 4:27 PM, Hans Dockter wrote: > > > > > On Tue, Nov 13, 2012 at 11:43 PM, Adam Murdoch < > [email protected]> 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. >> > > Good point. I would like to provide an example. A use case are jars where > the certificate needs to be renewed but people want to stick with the > version. Than this combination mentioned here (dynamic + changing) makes > complete sense. > > BTW: The information whether a module is changing or not should belong for > many (all?) modules in the module descriptor. Possibly together with an > invalidation time. How things currently work with declaring the changing > nature on the client side is a work around. > > > Absolutely it is. It's the producer's business what scheme it will use to > publish a given thing. > > However, all meta-data should be overridable in the consumer, including > whether and how often something may change. > I fully agree. Hans > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > >
