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.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com

Reply via email to