Document api dependencies between WALA projects, and use more where appropriate

[msridhar]

It seems our current policy with api dependencies in Gradle is to use them only when a public API mentions some type in the dependent library, e.g. here:

https://github.com/wala/WALA/blob/e53439ee174af62652883687513ad4d595915efb/com.ibm.wala.cast.js/build.gradle#L2-L4

I think we should be more liberal here. In most (nearly all?) cases, when a client depends on WALA project X, they also end up adding a dependence on all other WALA projects that X depends on. E.g., if someone wants to do JavaScript analysis and adds a dependence to wala.cast.js.rhino, they will almost certainly end up adding dependencies to wala.cast.js, wala.cast, wala.core, etc. In fact, I just tested it, and with our current api dependencies all you need to add is wala.cast.js.rhino and wala.cast.js and you end up getting the remaining projects as deps.

So, the proposal is to set a consistent policy of just using api dependencies between WALA projects. Then, users will likely only have to add a dependence on one WALA project and they will get the other ones automatically.

@liblit thoughts?

[liblit]

When I first split these dependencies into api versus implementation, I took a minimalist approach: implementation everywhere possible, api only where required. My reasoning was that under-exposure of transitive dependencies (implementation instead of api) would be easy enough to discover and correct later, whereas over-exposure (api instead of implementation) would just work, but perhaps not as well as it could.

I recommend reviewing the claimed benefits of dependency separation as described here, under “This comes with several benefits”. If those benefits do not apply here, or are smaller than the harm brought by making WALA harder to use, then I am fine with changing WALA-to-WALA dependencies to api throughout.

[msridhar]

Ok thanks @liblit. I'm not sure what is the best way to proceed here. When I revamp documentation a bit more I will think more about it.