java_library: provide a way to specify non transitive dependencies

[davido]

When building a plugin (P) for an existing system (S) which exposes an API in form of library (A) the following idiom is used:

P depends on A but java_binary P must not contain the content of A.
That's because P is deployed in S and all artifacts from A are obviously exist.

Currently it is not possible to express that idiom with Buck's native java_library.

Sugestion: extend java_library with new parameter: compiled_deps.

Alternatively provide a new finction java_library2 that exposes that parameter.

Working use case: java_library2() that exposes compile_deps parameter in:

https://github.com/davido/gerrit-reviewers-plugin/blob/master/lib/build.defs

To see the difference between call to java_library2 and java_library try to replace it on line 61: in gerrit_plugin() definition:

java_library(
name = name + '__plugin',
srcs = srcs,
resources = resources,
deps = deps + ['//:%s-lib' % type],
)

With the outcome that reviewers.jar would contain the whole gerrit-plugin-api.jar and not only 4 classes it adds.

[thkoch2001]

Maybe it'd make sense to use the same wording as used in maven: "provided"?

Maven documentation: Introduction to the Dependency Mechanism

Thank you for working on an alternative to maven!!!

[spearce]

I would suggest adding compile_deps to java_library(), e.g.:

java_library(
name = 'api',
srcs = glob(...),
deps = ['//lib:guava'],
compile_deps = ['//lib:servlet-api'],
)

deps is transitive, while compile_deps is only passed to the javac
invocation and is not exposed to java_binary() that includes this
library.

[davido]

Done in [1].

[1] davido@2d27e26

[shs96c]

After discussion on #68 this has been implemented in cea4e34 The documentation can currently be found here:
http://facebook.github.io/buck/rule/java_library.html