On 27/03/2012, at 6:04 AM, Szczepan Faber wrote: > Cool discussion. I do like this idea of modelling the resource VS artefact.
I've started down this path, and it's in master. > > * I change the system clock between publications of a changing artefact. Say > I publish an artefact, then move the clock back 1 hour, then publish the > artefact again. The timestamp on the newer artefact is earlier than the older > artefact. > > This is a real - we had that few times at the corpo, i.e. out-of-sync system > clocks led to insane issues in the mavenized environment. > > In short, relative comparison of timestamps is always a bad idea. We should > be treating them as opaque identifiers (i.e. can only check for equality) and > never on their own (i.e. include length as well). > > I'm sold. Interestingly, I hit a quirk of this approach testing my changes. We have an integration test that publishes a module then changes it instantly (in < 1 sec). HTTP dates have second fidelity. The test was changing the content, without changing the file length and the modification date difference was < 1 sec. A joy to debug, obvious in hindsight. This is pretty edge surely but I wonder if we should change our strategy. We could potentially prefer eTags and only fallback to last mod + content length if the server doesn't advertise eTags. We could then use if-none-match and avoid the extra head request. One problem here is that we expect servers to be compliant and implement if-none-modified properly, which they don't all do (I'm looking at you Artifactory). One option could be that we record the value of the “server” header in the external resource metadata and use it to make decisions. We might be starting to get too complex here though for negligible benefit. We potentially could use this to deal with weird servers like google code. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com
