Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jgit-dev] Introduction of new dependency (Apache Commons Codec or Guava) into JGit?

I have some commits in both repos so I could say they be both good repos, with good maintenance from good people.
However according to the situation here I think commons compress is more suitable.
1. It evolves slower. Well commons libs actually don't change much things in these 10 years or so, especially when you see it from compatibility side.
However guava, well, they moves really fast, and have more than 50+ major versions. So as a basic lib jgit might better choose commons compress.(well if you saying for a micro-service things might be quite different.)
And guava have some versions, for jre, for android, etc.
So I would not recommend you using guava as a lib, please imagine if a microservice using a different guava version than you choose and wanna use jgit also, well the BC issues would be a headache(even nightmare)
2. It is smaller than guava. guava's jar seems 10+ times larger than commons-compress.

Thomas Wolf <twolf@xxxxxxxxxx> 于2023年4月7日周五 17:56写道:
On 07.04.23 00:17 , Jonathan Tan via jgit-dev wrote:
> I'm looking into implementing changed-path bloom filters in JGit. In
> order for compatibility with the same feature in C Git, I need an
> implementation of the murmur3 hash. Apache Commons Codec and Guava
> both have an implementation, but neither of them are currently used by
> JGit. For what it's worth, JGit already uses another Apache Commons
> library (Compress, not Codec).
> What do people think about adding one of these libraries as a
> dependency? This does mean that downstream projects will need to
> include the library when creating their packages, if they are not
> already using it. From a brief survey, EGit uses neither, while Gerrit
> uses both.

If possible I'd prefer commons-codec. Eclipse simultaneous release has
had trouble in the past with Guava. (Don't remember the details.)



jgit-dev mailing list
To unsubscribe from this list, visit

Back to the top