Robert, >From the blog entry:
*Actually changing Maven Central to do this* The maven ‘deploy’ workflow and plugin would invisibly do a commit to (or create of) a dedicated Git repo up on central. For XStream, a new deployment would not go into http://central.maven.org/maven2/com/thoughtworks/xstream/xstream/ any more. Instead they would go into (say) g...@central.maven.org: maven2/com/thoughtworks/xstream/xstream.git The maintainer for the group:artifact would not have to do anything different to exist in the new deploy world, all the heavy lifting is done in Maven Central and that future version of the deploy plugin. They would have to upgrade their project to that deploy plugin, of course. It is not just Maven Central. It would be Artifactory, Nexus, Gradle (etc) technologies too. I just put it on Github as that is an easy place to do look-here-see-bro discussions. :) - Paul On Wed, May 17, 2017 at 3:29 PM, Robert Scholte <rfscho...@apache.org> wrote: > > On Wed, 17 May 2017 20:41:02 +0200, Paul Hammant <p...@hammant.org> 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 <rfscho...@apache.org> >> 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 <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 >>>>> > > >>>>> > > >>>>> > >>>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org >
