Menu
▾
▴
1 Attachments
#293 Move 3rd party jars out of FB source repository
closed-rejected
5
2017-10-22
2013-11-23
No
As proposed by Dave, we should consider moving 3rd party libraries out of the source code base.
AS IS:
The huge FB repository size is caused mostly by including few 3rd party libraries, see attached screenshot.
65% of the FB working tree (~85MB) is used by server/sandbox libraries. This is not nice, considering that FB core sources are about 12 MB only.
The "bare" Git repository size today (all FB history up to 2.0.3 but without working tree) is ~200 MB, with ~80% of it's filled by multiple old server/sandbox libraries.
TO BE:
Ideally only source code is included into the source repository. The required libraries should be downloaded from Internet on build.
This request requires (bigger) changes in build system.
I've removed dependencies from the main FindBugs project in https://code.google.com/r/klubick-findbugs/, from commits 8a1a85a3..7210bb08
I deleted the jars and added an ant target that downloads them from Maven. It deletes them and redownloads them every time, so you may wish to change that (by removing the dependency on "clean"
As far as I can tell, bluej/lib, findbugsTestCases\lib and webCloudProtocol\lib also need cleaning.
Thanks,
the changes make definitely sense and we should target for FB 3.0.2.
BUT.
I would not merge the current state to findbugs, see below.
Commit https://code.google.com/r/klubick-findbugs/source/detail?r=9c33e4c563806d26f37f32fed9b66b9427c59e37
removes findbugs builder from project. Why?
Commit https://code.google.com/r/klubick-findbugs/source/detail?r=0bfdb4155a2651158c0435c60ee706a3ca868ebf
fetches same jar 8 times. ????
Commit https://code.google.com/r/klubick-findbugs/source/detail?r=6b5ef067d40ec2cce9959c51fb0e2fec3b708b3b
adds hamcrest dependency to the findbugs project. Why??
I'm also pretty sure that the (renamed) jars were referenced in various other places (MANIFEST.MF in eclipsePlugin for example, poms etc).
Can you please start a separated branch where all the (cleaned up) changes were made?
Many thanks for looking into this issue. It would be very cool to get rid of all the external jars checked into the SCM.
Regards,
Andrey
Andrey, It appears I was a bit clumsy with my commits.
I had removed that (temporarily) because with Eclipse was struggling when I kept renaming jars. I had not meant to check that in.
Hmm.. must have not saved the build.xml before making that commit. You'll notice the next commit has the proper jar fetching.
This one was not, in a stirring turn of events, due to me being clumsy. As the commit message suggests, the original junit.jar had the hamcrest packages in it, but the one this script downloads from maven does not have that dependency. Without the hamcrest jars, there are a few compilation errors, so I added it in.
Yes. I can make a branch where I'll squash together the broken parts and I can more carefully check out other things that might break because of the renamed jars (for example, here). I'll try to get that in later today.
Thank you for the review.
I cleaned up my change history a bit and fixed a few more places impacted by the jar renaming. See revisions 8dfe1fe..35984bc5 in my creatively named branch "removing_jars"
I hope that looks a bit cleaner.
I realize these won't get pulled in until 3.0.1 is out the door, but I commented here to get feedback sooner rather than later.
Update:
Commits 27dcba84aaccce6..0e803d1a removes the jars from findbugsTestCases.
Next up is the plugins folder (and then maybe sandbox)
Kevin, please be careful and change only related stuff.
First commot from your last comment changed the classpath for testcases project from explicit 1.8 to "something".
Regards,
Andrey
Good catch Andrey,
I restaged those changes and force pushed on that branch. The commits of interest are now from 8f856d672c..9e62b53b1