Of course that content-based-storage system isn't a whole FS. That'll take
us back to where we were with some of the ClearCase modes of operaton where
all IO slowed down. Or worse - PVCS Dimensions in regular use. It's just
for read only pieces of our build-centric world.
-ph
On Thu, May 18,
You know, I think it would be cool if there were file systems that would
implement a form of a 'link' as part of a content-based-storage mechanism
like Git itself. Meaning if I ran the above git-clone/jar command twice in
two different directories it would only store the result once (assuming
>
> I'm not sure I'm not mistaken for the read part: with the current repo
> format,
> one thing that is super easy is that each artifact version is just a path
> that
> you can use simultaneously in one build or in multiple builds
>
e.g.
build #1 using --classpath
Le mercredi 17 mai 2017, 14:46:13 CEST Paul Hammant a écrit :
> > 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.
:)
I'm not sure I'm not mistaken for the read part:
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 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
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
Actually I'm proposing a predictable structure on 'central :
g...@central.maven.org:
maven2/
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
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)
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
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) -
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
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
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
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
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
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
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
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
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,
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
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
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
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
There's one repo per thing that is versioned. All these are separate repos
g: com/thoughtworks/paranamer a: paranamer type: javadoc is one repo
g: com/thoughtworks/paranamer a: paranamer type: sources is one repo
g: com/thoughtworks/paranamer a: paranamer type: classes is one repo
Interesting idea! All for experimenting with git!
You did not take into account the protocol differences, fetching a single
8MB jar from Maven Central is easy, while fetching 6 MB via multiple git
HTTP resources (even assuming git packs there will be multiple http calls)
is probably more
This is quite similar to what "go get" does to golang. I'd say its worth a
try
On May 14, 2017 09:28, "Paul Hammant" wrote:
> Article updated to eliminate misunderstandings and talk about a different
> index for 'maven central' too.
>
> - ph
>
> On Sat, May 13, 2017 at 3:04
Article updated to eliminate misunderstandings and talk about a different
index for 'maven central' too.
- ph
On Sat, May 13, 2017 at 3:04 PM, Paul Hammant wrote:
> I was discussing this of the list today, and it may interest people on dev@
>
>
I was discussing this of the list today, and it may interest people on dev@
https://paulhammant.com/2017/05/13/maven-central-as-multiple-git-repos/
"Maven Central as multiple Git repositories"
Enjoy,
- Paul
31 matches
Mail list logo