Hervé, on classes branch, splitting the jar into individual .class has IMHO a big > drawback: we loose original jar and its signature >
Agree. Git doesn't care about timestamps for classes in jars. Java doesn't either, but SHA1 (etc) of the jar does. Thus - the next iteration will reproduce even the timestamps of a resulting jar. > > On the other branches, the current poc shows commits for versions that are > perfectly linear: if there are multiple branches that are released in > parallel, the commit won't be so clean. I don't know if this will have an > impact on compression efficiency. > They can go in any random order (I tested) and Git achieves the same over all saving. > > Another issue with this idea: during development, with SNAPSHOTs, the git > repo > will be polluted: this idea IMHO could only be valid for releases > That's true. I'm really only focussed on the bring-down-from-maven-central cycle. Obviously I need an answer for the on-workstation workflow which inserts into ~/.m2/repository/ too. > > not to speak about read concurrency when one requires to use multiple > versions > of a lib. And of course, write concurrency is even harder. > I'm not following, dude. - Paul
