thats my point: the golang approach does no magic at all. It simply stores
the source code and bases it on a convention. Just the files, and thats it.

--
-- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal

On Wed, May 17, 2017 at 2:38 PM, Paul Hammant <p...@hammant.org> wrote:

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

Reply via email to