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

[Paul Hammant]

And as I'm comfortable advocating for a few Git-centric alternates, GitHub
could be a hosting platform for jars of classes too.  I think I've
established that it is efficient for storing binary classes.

The https://github.com/paul-hammant/mc-xs-classes/releases page on the
mc-xs-classes I did for the blog entry, has downloads of tags. That's all
the classes you'd want and the manifest in a a zip. The trouble is GitHub
made a root directory which will break Java.

So I raised a feature request - https://cloud.githubusercontent.com/assets/
82182/26177670/9d0cc4b8-3b28-11e7-88e1-7e97f727623c.png

Don't worry, I'm 0 for 10 or so.

- Paul

On Wed, May 17, 2017 at 5:37 PM, Paul Hammant  wrote:

> The Maven-using developer community cares that the dependency downloader
> does its think that the uploader/deploy does too. Some new releases of
> those, and some back releases for the hard breaks (if any) going back in
> time - Maven1, Maven2 and whatever.
>
> Works well enough for Homebrew (https://github.com/homebrew - the core
> repo is at 125MB). Sure there's been teething troubles, and Ruby was the
> wrong choice for the DSL versus Python, but it is great really.
>
>
>
> On Wed, May 17, 2017 at 5:25 PM, Manfred Moser 
> wrote:
>
>> 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 :
>> >
>> > g...@central.maven.org:
>> > maven2/> >
>> > (one minor fix versus previous description of the git:// location)
>> >
>> > Or for the three separate variant:
>> >
>> > g...@central.maven.org:
>> > maven2/> > g...@central.maven.org:
>> > maven2/> > g...@central.maven.org:
>> > maven2/> >
>> > 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 <
>> manf...@simpligility.com>
>> > 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: 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
>>
>>
>

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

[Paul Hammant]

The Maven-using developer community cares that the dependency downloader
does its think that the uploader/deploy does too. Some new releases of
those, and some back releases for the hard breaks (if any) going back in
time - Maven1, Maven2 and whatever.

Works well enough for Homebrew (https://github.com/homebrew - the core repo
is at 125MB). Sure there's been teething troubles, and Ruby was the wrong
choice for the DSL versus Python, but it is great really.



On Wed, May 17, 2017 at 5:25 PM, Manfred Moser 
wrote:

> 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 :
> >
> > g...@central.maven.org:
> > maven2/ >
> > (one minor fix versus previous description of the git:// location)
> >
> > Or for the three separate variant:
> >
> > g...@central.maven.org:
> > maven2/ > g...@central.maven.org:
> > maven2/ > g...@central.maven.org:
> > maven2/ >
> > 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  >
> > 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: 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
>
>

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

[Manfred Moser]

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 :
> 
> g...@central.maven.org:
> maven2/ 
> (one minor fix versus previous description of the git:// location)
> 
> Or for the three separate variant:
> 
> g...@central.maven.org:
> maven2/ g...@central.maven.org:
> maven2/ g...@central.maven.org:
> maven2/ 
> 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 
> 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: 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

Re: Open Maven resolvers issue and release 1.1.0

[Robert Scholte]

On Wed, 17 May 2017 12:38:53 +0200, Michael Osipov   
wrote:



Here are some minor issues for 1.1.0:
MRESOLVER-22 Upgrade to Maven Parent 30
MRESOLVER-23 Avoid implicit primitive type casts
MRESOLVER-24 Turn some IllegalArgumentExceptions into  
IllegalStateExceptions


Who seconds them?


3* +1

Robert



-
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

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

[Paul Hammant]

Actually I'm proposing a predictable structure on 'central :

 g...@central.maven.org:
maven2/
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: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

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

[Manfred Moser]

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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

[Paul Hammant]

I'm "just" unzipping the source, and committing those sources. Sure, I
delete the previous set first, but I merge the *rm* set and *add* set into
one commit with an --amend ->

 # fn is xstream-1.4.3.jar and v is 1.4.3 for example

 git("rm", "-r", "*")

git("commit", "-m", v)
wget(root + url + "/" + v + "/" + fn)
unzip(fn)
rm(fn)
git("add", ".")
git("commit", "-m", v, "--amend")

On Wed, May 17, 2017 at 3:41 PM, Aldrin Leal  wrote:

> 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,  / http://about.me/aldrinleal
>
> On Wed, May 17, 2017 at 2:38 PM, Paul Hammant  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  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,  / http://about.me/aldrinleal
> > >
> > > On Wed, May 17, 2017 at 1:49 PM, Paul Hammant 
> 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 
> > wrote:
> > > >
> > > > > Still, once github gets an outage, our repositories are basically
> > > > > 'left-padded' (taken offline)
> > > > >
> > > > > --
> > > > > -- Aldrin Leal,  / http://about.me/aldrinleal
> > > > >
> > > > > On Wed, May 17, 2017 at 1:35 PM, Paul Hammant 
> > > 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,  /
> > 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 

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

[Paul Hammant]

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 
wrote:
>
> On Wed, 17 May 2017 20:41:02 +0200, Paul Hammant  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 
>> 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 
>>> 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,  / http://about.me/aldrinleal

 On Wed, May 17, 2017 at 9:37 AM, Paul Hammant  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  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
> > > 

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

[Aldrin Leal]

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,  / http://about.me/aldrinleal

On Wed, May 17, 2017 at 2:38 PM, Paul Hammant  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  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,  / http://about.me/aldrinleal
> >
> > On Wed, May 17, 2017 at 1:49 PM, Paul Hammant  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 
> wrote:
> > >
> > > > Still, once github gets an outage, our repositories are basically
> > > > 'left-padded' (taken offline)
> > > >
> > > > --
> > > > -- Aldrin Leal,  / http://about.me/aldrinleal
> > > >
> > > > On Wed, May 17, 2017 at 1:35 PM, Paul Hammant 
> > 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 
> > > > 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,  /
> http://about.me/aldrinleal
> > > > > >
> > > > > > On Wed, May 17, 2017 at 9:37 AM, Paul Hammant 
> > > > 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  >
> > > > 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
> > > > 

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

[Paul Hammant]

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  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,  / http://about.me/aldrinleal
>
> On Wed, May 17, 2017 at 1:49 PM, Paul Hammant  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  wrote:
> >
> > > Still, once github gets an outage, our repositories are basically
> > > 'left-padded' (taken offline)
> > >
> > > --
> > > -- Aldrin Leal,  / http://about.me/aldrinleal
> > >
> > > On Wed, May 17, 2017 at 1:35 PM, Paul Hammant 
> 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 
> > > 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,  / http://about.me/aldrinleal
> > > > >
> > > > > On Wed, May 17, 2017 at 9:37 AM, Paul Hammant 
> > > 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 
> > > 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

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

[Robert Scholte]

On Wed, 17 May 2017 20:41:02 +0200, Paul Hammant  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 
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 
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,  / http://about.me/aldrinleal

On Wed, May 17, 2017 at 9:37 AM, Paul Hammant  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  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  


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

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,  / http://about.me/aldrinleal

On Wed, May 17, 2017 at 1:49 PM, Paul Hammant  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  wrote:
>
> > Still, once github gets an outage, our repositories are basically
> > 'left-padded' (taken offline)
> >
> > --
> > -- Aldrin Leal,  / http://about.me/aldrinleal
> >
> > On Wed, May 17, 2017 at 1:35 PM, Paul Hammant  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 
> > 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,  / http://about.me/aldrinleal
> > > >
> > > > On Wed, May 17, 2017 at 9:37 AM, Paul Hammant 
> > 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 
> > 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 

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

[Paul Hammant]

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

> Still, once github gets an outage, our repositories are basically
> 'left-padded' (taken offline)
>
> --
> -- Aldrin Leal,  / http://about.me/aldrinleal
>
> On Wed, May 17, 2017 at 1:35 PM, Paul Hammant  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 
> 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,  / http://about.me/aldrinleal
> > >
> > > On Wed, May 17, 2017 at 9:37 AM, Paul Hammant 
> 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 
> 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,

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

[Paul Hammant]

Hervé,

on classes branch, splitting the jar into individual .class has IMHO a big
> drawback: we loose original jar and its signature
>

Agree. Git doesn't care about timestamps for classes in jars. Java doesn't
either, but SHA1 (etc) of the jar does.

Thus - the next iteration will reproduce even the timestamps of a resulting
jar.


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

They can go in any random order (I tested) and Git achieves the same over
all saving.


>
> Another issue with this idea: during development, with SNAPSHOTs, the git
> repo
> will be polluted: this idea IMHO could only be valid for releases
>

That's true. I'm really only focussed on the bring-down-from-maven-central
cycle. Obviously I need an answer for the on-workstation workflow which
inserts into ~/.m2/repository/ too.


>
> not to speak about read concurrency when one requires to use multiple
> versions
> of a lib. And of course, write concurrency is even harder.
>

I'm not following, dude.

- Paul

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

[Aldrin Leal]

Still, once github gets an outage, our repositories are basically
'left-padded' (taken offline)

--
-- Aldrin Leal,  / http://about.me/aldrinleal

On Wed, May 17, 2017 at 1:35 PM, Paul Hammant  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  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,  / http://about.me/aldrinleal
> >
> > On Wed, May 17, 2017 at 9:37 AM, Paul Hammant  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  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
> > > > >
> > > > >
> > > > >
> > > > > 

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

[Paul Hammant]

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.  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 
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 
> 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,  / http://about.me/aldrinleal
>>
>> On Wed, May 17, 2017 at 9:37 AM, Paul Hammant  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  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 
>>> > 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,
>>> > > > 

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

[Paul Hammant]

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  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,  / http://about.me/aldrinleal
>
> On Wed, May 17, 2017 at 9:37 AM, Paul Hammant  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  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 
> > > 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
> > > >
> > > >
> > >
> >
>

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

[Robert Scholte]

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  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,  / http://about.me/aldrinleal

On Wed, May 17, 2017 at 9:37 AM, Paul Hammant  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  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 
> 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

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

[Aldrin Leal]

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,  / http://about.me/aldrinleal

On Wed, May 17, 2017 at 9:37 AM, Paul Hammant  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  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 
> > 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
> > >
> > >
> >
>

Re: Maven-monitor still in use?

[Paul Hammant]

Given the version spread of Maven-Monitor above (v2.0.5 and v2.0.9 needed
to build v2.2.1) I'd love to get some advice to how to attach breakpoints
in use to see the pertinent methods invoked during a build.  I mean I've
attached breakpoints and then done mvnDebug but the breakpoints are not hit.

I'm trying to work out what a phase listener would look like, and thought
that the closed API to something that participates in the phase traversal
is MavenMonitor.  Advice please?

- Paul

On Fri, May 12, 2017 at 6:01 AM, Paul Hammant  wrote:

> I''m looking to make a build radiator. Something like this -
> https://www.stevefenton.co.uk/wp-content/uploads/2015/07/cruiser.jpg
>
> I don't want to scrape logs to detect maven phase changes, and
> corresponding pass/fail, I want to use a plugin. I think that plugin
> is Maven-monitor
>
> Online documentation for that is here http://maven.apache.org/ref/2.
> 2.1/maven-monitor/ and that doesn't say much, except to direct the user
> to subversion (where the plugin still resides).
>
> In use a few versions can be downloaded* - meaning even if I could make my
> own version of Maven monitor, I would struggle to get it used exclusively
> through the entire 'mvn' invocation.
>
> Advice ?
>
> * e.g.the build for maven-monitor-2.2.1 downloads v2.0.5 AND v2.0.9 of
> itself. Different projects are going to download/use multiple different
> versions of course.
>
> - Paul
>

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

[Paul Hammant]

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

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

[Brian Fox]

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

Re: Open Maven resolvers issue and release 1.1.0

[Michael Osipov]

Here are some minor issues for 1.1.0:
MRESOLVER-22 Upgrade to Maven Parent 30
MRESOLVER-23 Avoid implicit primitive type casts
MRESOLVER-24 Turn some IllegalArgumentExceptions into IllegalStateExceptions

Who seconds them?


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven issue #109: Updated Mockito, slf4j and logback dependences to latest v...

[ebourg]

Github user ebourg commented on the issue:

https://github.com/apache/maven/pull/109
  
#118 also upgrades SLF4J but goes a bit further by removing the patching 
mechanism.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven issue #118: Upgrade SLF4J to 1.7.25

[ebourg]

Github user ebourg commented on the issue:

https://github.com/apache/maven/pull/118
  
It's better now, the levels and the exceptions are properly colored, and 
SLF4J no longer complains about the duplicate StaticLoggerBinder.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven issue #118: Upgrade SLF4J to 1.7.25

[ebourg]

Github user ebourg commented on the issue:

https://github.com/apache/maven/pull/118
  
Understood, thank you. I've added a StaticLoggerBinder implementation but 
now SLF4J complains that there are two StaticLoggerBinder on the classpath 
(from maven-slf4j-provider and slf4j-simple). I'll try to shade slf4j-simple 
and remove its StaticLoggerBinder class.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org