On 14/11/2012, at 4:27 PM, Hans Dockter wrote: > > > > On Tue, Nov 13, 2012 at 11:43 PM, Adam Murdoch <adam.murd...@gradleware.com> > 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. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
