Re: [jgit-dev] JGit DFS code in main bundle?
+1 to having DFS as a separate artifact/bundle.
Agit uses ProGuard in it's build process for control flow analysis to detect & remove unused classes/fields, and this trims about 25% from the footprint of the JGit classes - and in fact, it currently completely removes the org.eclipse.jgit.storage.dfs package from the resulting jar, so we don't pay a size penalty in the resulting android package, but do pay a penalty for the increased build time due to the analysis on the additional classes. Due to that, and to guard against unintended dependencies on the DFS code being introduced, I'm definitely +1 on having a separate artifact.
On 30 November 2011 07:30, Shawn Pearce <spearce@xxxxxxxxxxx>
Are we worried about how big the main JGit JAR is?
Reason I ask... the JGit DFS code is part of the main JGit JAR. But
there are probably no clients that actually use it except me right
now. I wonder if this should be in its own Maven artifact and P2
bundle, so that clients like Agit aren't forced to carry the DFS
classes that are not likely to be invoked by Agit on a small mobile
I got lazy and contributed everything as a new package in the main
JGit bundle. I wonder if we shouldn't shuffle this to its own bundle
before we cut the next release.