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. > > > [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. > yes. Hans > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > >
