On Wed, 17 May 2017 20:41:02 +0200, Paul Hammant <[email protected]> wrote:

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.

So suppose I want to add xstream-1.4.9 as dependency to my project. How should Maven know it has to go to https://github.com/paul-hammant/mc-xs-classes? You need some kind of mapping, and with this structure you have to do it for every git-stored dependency. The most straight-forward solution would be to add repositories (which might fit in POM model 4.0.0), but I cannot imagine users want to do that for every dependency.

Robert


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]


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

Reply via email to