I would agree that it has the potential to be a new repository implementation, Robert. But I am not sure I follow your second sentence. Maybe I do. There is one Git repo per group/artifact. That's true for whether it is the principal artifact you're after or a transitive dep.
1. For https://github.com/paul-hammant/mc-xs-all I have the sources, classes, and javadoc as separate branches in one repo. 2. For https://github.com/paul-hammant/mc-xs-classes and https://github.com/paul-hammant/mc-xs-javadocs and https://github.com/paul-hammant/mc-xs-sources I have three Git repos per group/artifact. #1 and #2 are alternate coices. #1 has poms in their own branch in that Git repo too - and they too are one-line retrievable from the remote. - Paul On Wed, May 17, 2017 at 1:27 PM, Robert Scholte <[email protected]> wrote: > I consider this as a new repository implementation. But this also implies > that in your pom, for every dependency you have to add a repository-entry > as well, right? > > Robert > > > On Wed, 17 May 2017 17:10:49 +0200, Aldrin Leal <[email protected]> > wrote: > > Just a friendly reminder that git is not optimized for large files (for >> this, they made git-lfs). Plus, when you do checkout a git repo, there's >> no >> binary diffs - so if you've got plenty of releases, you'll be wasting a >> lot >> of space/time in terms of transmission and storage. >> >> -- >> -- Aldrin Leal, <[email protected]> / http://about.me/aldrinleal >> >> On Wed, May 17, 2017 at 9:37 AM, Paul Hammant <[email protected]> wrote: >> >> We can agree to differ on what I'm suggesting and what the impact of that >>> would be :) >>> >>> On Wed, May 17, 2017 at 8:59 AM, Brian Fox <[email protected]> wrote: >>> >>> > Even more than redefining what Central does, you're effectively >>> describing >>> > a new, unofficial java class packaging and distribution mechanism. This >>> > seems like it will violate signatures etc and make tracking of what you >>> > actually have a nightmare. >>> > >>> > On Tue, May 16, 2017 at 5:55 PM, Hervé BOUTEMY <[email protected]> >>> > wrote: >>> > >>> > > this idea of putting everything in git is funny: not sure this will >>> go >>> > very >>> > > far from this poc, but let's imagine... >>> > > >>> > > on classes branch, splitting the jar into individual .class has IMHO >>> a >>> > big >>> > > drawback: we loose original jar and its signature >>> > > >>> > > 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. >>> > > >>> > > Another issue with this idea: during development, with SNAPSHOTs, the >>> git >>> > > repo >>> > > will be polluted: this idea IMHO could only be valid for releases >>> > > >>> > > not to speak about read concurrency when one requires to use multiple >>> > > versions >>> > > of a lib. And of course, write concurrency is even harder. >>> > > >>> > > >>> > > Definitely, the idea is funny, but I don't see how this could go very >>> far >>> > > than >>> > > this funny idea (in addition to the complexity for implementing this >>> > > format in >>> > > tooling) >>> > > >>> > > Regards, >>> > > >>> > > Hervé >>> > > >>> > > Le lundi 15 mai 2017, 21:45:00 CEST Paul Hammant a écrit : >>> > > > One more repo: >>> > > > >>> > > > https://github.com/paul-hammant/mc-xs-all/ >>> > > > >>> > > > One branch for each of classes, javadoc, sources, and poms >>> > > > >>> > > > 15 javadoc original versions: 24.1M >>> > > > >>> > > > 16 sources original versions: 4.9M >>> > > > >>> > > > 27 classes original versions: 8.4M >>> > > > >>> > > > Afterwards git work the bare .git folder is: 8.4M >>> > > > >>> > > > *77.5% saving on storage* >>> > > > >>> > > > Any artifact, *including the poms,* can be pulled down via a single >>> git >>> > > > command >>> > > > >>> > > > git clone https://github.com/paul-hammant/mc-xs-classes --depth 1 >>> > > --branch >>> > > > TAGNAME >>> > > > >>> > > > 74 TAGNAMEs: classes-0.1, classes-0.2, classes-0.3, classes-0.5, >>> > > > classes-0.6, classes-1.0, classes-1.0.1, classes-1.0.2, >>> classes-1.1, >>> > > > classes-1.1.1, classes-1.1.2, classes-1.1.3, classes-1.2, >>> > classes-1.2.1, >>> > > > classes-1.2.2, classes-1.3, classes-1.3.1, classes-1.4, >>> classes-1.4.1, >>> > > > classes-1.4.2, classes-1.4.3, classes-1.4.4, classes-1.4.5, >>> > > classes-1.4.6, >>> > > > classes-1.4.7, classes-1.4.8, classes-1.4.9, javadoc-1.2, >>> > javadoc-1.2.1, >>> > > > javadoc-1.2.2, javadoc-1.3, javadoc-1.3.1, javadoc-1.4, >>> javadoc-1.4.1, >>> > > > javadoc-1.4.2, javadoc-1.4.3, javadoc-1.4.4, javadoc-1.4.5, >>> > > javadoc-1.4.6, >>> > > > javadoc-1.4.7, javadoc-1.4.8, javadoc-1.4.9, pom-1.2, pom-1.2.1, >>> > > pom-1.2.2, >>> > > > pom-1.3, pom-1.3.1, pom-1.4, pom-1.4.1, pom-1.4.2, pom-1.4.3, >>> > pom-1.4.4, >>> > > > pom-1.4.5, pom-1.4.6, pom-1.4.7, pom-1.4.8, pom-1.4.9, >>> sources-1.1.3, >>> > > > sources-1.2, sources-1.2.1, sources-1.2.2, sources-1.3, >>> sources-1.3.1, >>> > > > sources-1.4, sources-1.4.1, sources-1.4.2, sources-1.4.3, >>> > sources-1.4.4, >>> > > > sources-1.4.5, sources-1.4.6, sources-1.4.7, sources-1.4.8, >>> > sources-1.4.9 >>> > > > >>> > > > - Paul >>> > > >>> > > >>> > > >>> > > ------------------------------------------------------------ >>> --------- >>> > > To unsubscribe, e-mail: [email protected] >>> > > For additional commands, e-mail: [email protected] >>> > > >>> > > >>> > >>> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
