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

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

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

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

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

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

Re: Open Maven resolvers issue and release 1.1.0

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

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

Actually I'm proposing a predictable structure on 'central : g...@central.maven.org: maven2/

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

Re: Maven-monitor still in use?

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.

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

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

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

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

Re: Open Maven resolvers issue and release 1.1.0

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

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

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

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

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

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

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