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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
