Add executable as a direct dependency

[cocreature]

This PR fixes a bug where rootpath on a scala_binary resolved to the JAR instead of the wrapper binary.

This fixes a bug introduced by
#958. Before #958,
rootpath on a Scala binary resolved to the wrapper binary so other
rules could treat it as an opaque executable. After that PR rootpath
now resolves to the JAR instead of the wrapper binary.

Adding the executable back as a direct dependency fixes that.

Happy to try and add a test for this but I need some guidance how and where to test this.

Description

Motivation

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[cocreature]

@googlebot I signed it!

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[cocreature]

Following https://groups.google.com/g/bazel-discuss/c/oEyEIr7vaF4/m/0E5QaK46AQAJ it also needs to be in runfiles.

[ittaiz]

Thanks!
What were you trying to do and failed? That's usually the test we want :)
If the bug means you can't run scala binaries then it sounds we roughly have two options here:

1. We add an sh_test that depends on a scala_binary and tries to run that. I think that will work but not 100% sure and might require some tweaking. The plus side of this is that this test is part of bazel.
2. We add an e2e bash test (see our bash tests in the root of the repo) which can call bazel run on a binary and see that it printed something you expect.

If it's something else (because you mention something about other rules) then this again relates to my first sentence.

I want us to merge this with a test.

[cocreature]

sh_test should be good enough. That roughly mirrors what we were trying to do. I’ll see if I can get something working.

[cocreature]

I added a testcase. It is slightly convoluted since rootpath in a sh_test has some special treatment in Bazel so we need to call it in a genrule to observe the difference. Without this patch you will only get the JAR in the rootpaths which was also the behavior before the PR I linked to.

[simuons]

Hi @cocreature, could you run lint (ci is failing on that)?

[cocreature]

Done, sorry I missed the failure.

[simuons]

@ittaiz I think this is ready to be merged.