support neverlink in scala_library

[johnynek]

java rules support this, but we don't.

[sdtwigg]

This seems pretty straightforward to implement (just involves a little fiddling with setting up the jar lists in the provider). There might be a little incongruence with java interop until can safely use the new bazel CLs.

Do you know how to test it?

[ittaiz]

Stephen, Wdyt about sending a PR where the only blocker is that it uses bazel from head? Will enable to start flushing out problems.

…

On Fri, 2 Jun 2017 at 21:56 Stephen Twigg ***@***.***> wrote: This seems pretty straightforward to implement (just involves a little fiddling with setting up the jar lists in the provider). There might be a little incongruence with java interop until can safely use the new bazel CLs. Do you know how to test it? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#213 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUIF9_AdrF84w8nKmSoZBmtC1AKcD2Mks5sAFrvgaJpZM4Nupc6> .

[softprops]

What is neverlink?

[sdtwigg]

https://bazel.build/versions/master/docs/be/java.html#java_library.neverlink

Basically, when included, the jar is added to the compile path of dependents but not the runtime path or dependents (direct or transitive).

@ittaiz yes, a situation using neverlink just hasn't come up for me yet so would be aided by advice on testing it. (I suppose I could fake it by creating a neverlink target (with stub implementation) and then a similar target identical one (same interface, real implementation) that is included as a runtime_dep?)

[ittaiz]

The problem with testing neverlink is that the problem we're trying to solve in the lead target is potential and order based on the classpath. If the leaf will have the "correct" "linked" version first then there shouldn't be a problem. I have an idea which isn't very pretty but should work- have two targets with different names implement the same interface (can be same implementation) and assert in the test that only one of them is in the classpath. The downside to this test is that it doesn't demonstrate why it's a problem but because the problem is tricky to reproduce (the order of loading the jars) I think it's ok alongside a comment.

…

On Sat, 3 Jun 2017 at 0:32 Stephen Twigg ***@***.***> wrote: https://bazel.build/versions/master/docs/be/java.html#java_library.neverlink Basically, when included, the jar is added to the compile path of dependents but not the runtime path or dependents (direct or transitive). @ittaiz <https://github.com/ittaiz> yes, a situation using neverlink just hasn't come up for me yet so would be aided by advice on testing it. (I suppose I could fake it by creating a neverlink target (with stub implementation) and then a similar target identical one (same interface, real implementation) that is included as a runtime_dep?) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#213 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUIF302s3xPwW--w9lQGGG3GY5ukUVJks5sAH9YgaJpZM4Nupc6> .

[kien-truong]

Do we have any progress on this ? It'd be very useful to strip down jars of Spark jobs.

[smparkes]

FWIW, we had the spark use case and were able to get unblocked by using deploy_env:

https://docs.bazel.build/versions/master/be/java.html#java_binary.deploy_env
#576

[kien-truong]

Thanks for the tips. We've also succeeded in using deploy_env to strip out Spark's class.

[TheKaur]

@ittaiz Are we going to support neverlink for scala_library?

[ittaiz]

We can.
I think we haven't because no one cared enough to add it.

[TheKaur]

@ittaiz Is there someone who can help implement it? I am not at all versed with bazel code but can give it a shot if no one is available

[ittaiz]

@blorente @liucijus ?

[liucijus]

I will look into it

[liucijus]

Fixed by #1123