4

We have a Scala project with few source files (in Scala and Java) and quite some dependencies in various binary formats (jar and DLL). I'm wondering what should go into our shared git repo. Only the source files (developers have to download or somehow resolve the dependencies themselves) or the both the source files and the dependencies? I may add that dependencies are all third parties and available for download for free.

Craig P. Motlin
  • 26,452
  • 17
  • 99
  • 126
Ashkan Kh. Nazary
  • 21,844
  • 13
  • 44
  • 68

4 Answers4

7

We prefer to store .jar files in the same repository because

  • they are updated very seldom, so the overhead for old libraries is not much
  • we prefer self-contained bundles and don't want to set up an own Maven server
Mot
  • 28,248
  • 23
  • 84
  • 121
6

I would really recommend to not include jar and dll in a Git repo: it will make said repo quite big quickly, and the future git clone won't be as easy to do as with a simple source repository (as in "no binaries").

I would set up a Nexus repo, and manage your dependencies through sbt.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I may add that SBT does a very good job of "automatically" managing dependencies using Ivy technology in the background which in turn relies on maven style repositories to fetch everything. – Ashkan Kh. Nazary Jan 04 '11 at 08:33
  • Apparently Nexus is more suitable for large organizations in which an internal private maven repository makes sense. – Ashkan Kh. Nazary Jan 04 '11 at 08:34
  • @ashy_32bit: being in a large organization, I agree with you on the usage of a private Maven repo with Nexus. – VonC Jan 04 '11 at 08:55
4

Downloading the dependencies from somewhere else could be problematic: I think, you cannot assure that the version downloaded is still the version needed by your project. If there's further development on the dependencies, their interfaces may change and you'll have problems with that.

So, I'd recommend to put the dependencies into the git repo to assure that you're working with a consistent version of the dependencies. They won't change every week (they shouldn't), so the repo won't grow that quick. And disk space is cheap. So it's not that big problem.

If you want to save disk space, you could zip up the dependencies in one file (what will not have that big effect since jars are already archived).

eckes
  • 64,417
  • 29
  • 168
  • 201
1

There's two issues here:

  1. Managing dependencies during development
  2. Distributing dependencies to users

If all the developers have consistent access to the internet, and are not behind a proxy that makes it almost impossible for anything but Internet Explorer (or other app official configured by IT) to escape, then wherever possible I'd have them automatically downloaded by sbt or Maven and not include them in the source repository. For dependencies that cannot be automatically managed I would include them in the source repository. If making anything besides Internet Explorer get past the proxy server is an exercise in futility I'd put everything in the repository. I work at a big company, and lately sbt and Maven has been able to make it past the proxy, but I think in the past Maven has failed and there are many tools that are almost impossible to get through.

As for distribution, I'd make a build target that zips up everything required, including the dependencies, and I'd be very tempted to check it in to the repo so it doesn't get lost.

Erik Engbrecht
  • 3,174
  • 17
  • 23