Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove scala_library _deploy.jar target #21

Closed
smparkes opened this issue Mar 7, 2016 · 6 comments
Closed

remove scala_library _deploy.jar target #21

smparkes opened this issue Mar 7, 2016 · 6 comments

Comments

@smparkes
Copy link
Contributor

smparkes commented Mar 7, 2016

The scala_library _deploy.jar target has no equivalent meaning on the java side and is (probably?) unnecessary.

@smparkes
Copy link
Contributor Author

smparkes commented Mar 7, 2016

Ah. I see why this is necessary at this point, since java_* can't depend onscala_library directly.

@johnynek
Copy link
Member

johnynek commented Mar 7, 2016

but can't we solve that with #18 ?

@smparkes
Copy link
Contributor Author

smparkes commented Mar 7, 2016

Solve the necessity? Yeah, should be able to.

I just meant I see why we can't remove this until there's some other way of depending on scala libs.

@johnynek
Copy link
Member

johnynek commented Mar 7, 2016

still they are not "deploy_jars" as such because they don't have the transitive deps, right?

I wonder if fixing that is step 1.

@smparkes
Copy link
Contributor Author

smparkes commented Mar 7, 2016

Do you mean _deploy.jars for scala_binary or scala_library? Yeah, getting _deploy.jar fixed for scala_binary would be great.

I don't know that getting _deploy.jar working for scala_library is all that useful since the need for those files is really just an artifact of not being able to rely on scala_librarys in java_librarys. They could be called anything and still fill that role. And I don't think in that case that the libraries should be flattened. That sounds dicey/like an antipattern. That's what exports are for, isn't it?

@johnynek
Copy link
Member

this was made implicit (and as such optional) by #61 . It may go away in the future if bazelbuild/bazel#970 is fixed since the only reason they were kept now is to make exporting to java targets easier.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants