Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

Aldrin Leal
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, <[hidden email]> / http://about.me/aldrinleal

On Wed, May 17, 2017 at 1:49 PM, Paul Hammant <[hidden email]> 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 <[hidden email]> wrote:
>
> > Still, once github gets an outage, our repositories are basically
> > 'left-padded' (taken offline)
> >
> > --
> > -- Aldrin Leal, <[hidden email]> / http://about.me/aldrinleal
> >
> > On Wed, May 17, 2017 at 1:35 PM, Paul Hammant <[hidden email]> 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 <[hidden email]>
> > 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, <[hidden email]> / http://about.me/aldrinleal
> > > >
> > > > On Wed, May 17, 2017 at 9:37 AM, Paul Hammant <[hidden email]>
> > 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 <[hidden email]>
> > 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 <
> > > [hidden email]>
> > > > > > 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: [hidden email]
> > > > > > > For additional commands, e-mail: [hidden email]
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

Manfred Moser-4
If you would run Central on git like that in a centralized manner you would have to find someone that does that hosting for you and you would have to get buy in from the community to use that - both extremely hard or impossible.

And if you dont do that but instead go with the distributed system you end up with the registry model that I think just doesnt really work in the real world.

manfred

Paul Hammant wrote on 2017-05-17 13:39:

> Actually I'm proposing a predictable structure on 'central :
>
> [hidden email]:
> maven2/<group-name-with-slashes-for-dots</<artifact-name>.git
>
> (one minor fix versus previous description of the git:// location)
>
> Or for the three separate variant:
>
> [hidden email]:
> maven2/<group-name-with-slashes-for-dots</<artifact-name>-classes.git
> [hidden email]:
> maven2/<group-name-with-slashes-for-dots</<artifact-name>-javadocs.git
> [hidden email]:
> maven2/<group-name-with-slashes-for-dots</<artifact-name>-sources.git
>
> More likely though (as you mentioned in your opening line) is the way
> homebrew works - you point at repos elsewhere, but control poms/shas etc on
> 'central.
>
>
>
>
> On Wed, May 17, 2017 at 3:59 PM, Manfred Moser <[hidden email]>
> wrote:
>
>> Having worked with repository managers and the implementation for various
>> formats on Nexus for years I think such a format is a bit like Bower. It is
>> a registry format that in turn points to git repositories that have the
>> content.
>>
>> From a corporate usage and implementation point of view this is a utter
>> nightmare since you would have to open up your systems to all those
>> different repositories and sites hosting them instead of just one.
>>
>> You also cant simply make a copy of the content or analyze it in the way
>> it manifests as binaries.
>>
>> I am not sure what you are looking for as benefits but from my point of
>> view this is maybe a fun experiment but not something that will ever take
>> off..
>>
>> Manfred
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]