Aldrin, The blog entry I wrote on saturday mulled classes, javadocs and sources - https://paulhammant.com/2017/05/13/maven-central-as-multiple-git-repos/ (re your "way more than" comment).
The GH repo I linked you to earlier has all three in one repo (see the branches drop-down) - https://github.com/paul-hammant/mc-xs-all - Paul On Wed, May 17, 2017 at 2:54 PM, Aldrin Leal <ald...@leal.eng.br> wrote: > I understand the approach is basically general, but maven artifacts are way > more than binary code (there's source and javadoc). I also understand its > an interesting option for distribution. > > I really would like to see something close to what "go get" does. If not > github and bitbucket (and go get includes git, hg and bzr among scms), it > open the URL itself and resolve it into a(by means of HTML metadata). > > Just distributing the source allowing it to easily updates would be > awesome, since it would allow less effort to create and distribute. Of > course, we could have to limit the scope of what to do to avoid abuse. > > > -- > -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal > > On Wed, May 17, 2017 at 1:49 PM, Paul Hammant <p...@hammant.org> wrote: > > > There is that, yes. And Git's general upper limits which are subject of > "I > > heard of a team that had a corruption at 2GB". I've field tested Git up > to > > 7GB for a git-svn-clone myself (a team considering saying bye bye to > Svn), > > but wouldn't put that live versus hive off history to a R/O repo, and > start > > over with HEAD of the old becoming the initial commit of the new. > > > > - Paul > > > > On Wed, May 17, 2017 at 2:40 PM, Aldrin Leal <ald...@leal.eng.br> wrote: > > > > > Still, once github gets an outage, our repositories are basically > > > 'left-padded' (taken offline) > > > > > > -- > > > -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal > > > > > > On Wed, May 17, 2017 at 1:35 PM, Paul Hammant <p...@hammant.org> > wrote: > > > > > > > Aldrin - https://github.com/paul-hammant/mc-xs-all - no large files > > > added > > > > to Git. Git makes 70% saving on bytes used ('bare' mode). > > > > > > > > On Wed, May 17, 2017 at 11:10 AM, Aldrin Leal <ald...@leal.eng.br> > > > 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, <ald...@leal.eng.br> / http://about.me/aldrinleal > > > > > > > > > > On Wed, May 17, 2017 at 9:37 AM, Paul Hammant <p...@hammant.org> > > > 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 <bri...@infinity.nu> > > > 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 < > > > > herve.bout...@free.fr> > > > > > > > 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: dev-unsubscr...@maven.apache.org > > > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
