We have two in-house projects, A and B, developed by different teams with B dependent on A. Since source code for both projects is stored in git, I’ve included project A as a submodule into project B and configured the build system to build both in right order. An alternative solution would be to consume A via a binary repository manager such as Artifactory or Nexus.
I wonder about pros and cons of depending on source code vs depending on binary artifacts. When is one better than the other? So far I managed to come up with following factors, but I am really keen on hearing other opinions.
Depending on source code is better
- if you don’t have a binary repository manager
- if you need to depend on pre-release version of another project
- if you need to patch another project
- because it is easier to browse dependency source code in IDE
Depending on binaries is better
- to minimize build time
- to avoid the hassle of setting up another project’s build environment
1
I would always recommend binary dependencies over source dependencies. Most of the pros you list for source code can be easily incorporated into binary dependencies as well.
First, it is very quick to set up a Nexus repo on some local server. The benefits of having a binary repo far outweigh the setup effort/cost. This is almost a pre-requisite for the rest of my answer 🙂
For pre-release versions, your projects should be deploying -SNAPSHOT versions into the artifactory. There can be a nice and clear distinction between versions, such as:
projectA-3.2.0-SNAPSHOT: Active development, may change at any timeprojectA-3.2.0-RC1: Release candidateprojectA-3.2.0: Production release
All these versions can be stored together in your artifactory. Your projects would know exactly what they are compiling against.
For patches, git is your friend. Fork the repo and put in a patch version number, such as projectA-3.2.1-FOR_PROJ_B. Notice the .1 showing a patch release and also the descriptor. This will also make it easy for the project to pull in those changes back to the master later.
For source code, you can configure your build tool to generate a “source jar” and deploy it alongside the binary jar in the artifactory. Most IDEs can look-up the source jar name and automatically download the source for you.
Another big reason to stay away from source code is that you are tied to the build system, tool-chain and compile-time dependencies of Project A. If you see a build failure in Project B, you have to first investigate if Project A or Project B caused an error. If it was Project A, you have go track down people from that project to fix their build. This adds a lot of overhead to your build cycle.
1
I would go for binary dependency, because almost none of your considerations favouring me is without critic:
-
if you don’t have a binary repository manager: that is ok, but I do not think it is that difficult to stablish one. In the most basic level, a shared folder where only the people in charge to deciding which version use can write.
-
if you need to depend on pre-release version of another project: metacubed already covered it. Either with source code or binary dependencies, you should stick to a well-stablished version, even if it is pre-release. Of course, when developing against a pre-release, odds are that you will need switch to an updated version often due to bug solving.
-
if you need to patch another project: do you mean that your team is going to patch the project made from another team in the same house? I would say the most sane strategy is tell the other team the issues you have with their project.
-
because it is easier to browse dependency source code in IDE: You should not need to snoop into the inner workings of your dependencies, because it will mean:
- project A is poorly documented
- your coders will end using “undocumented features” of project A that may disappear without previous warning at any update.
4