Comments (18)
/cc @colinmarc @jcoveney
from rules_scala.
What about adding a java
provider to scala_library
? Will the java rules pick that up automatically?
from rules_scala.
Also, if that doesn't work, we could generate the java_import
rules preemptively as foo_javaimport
.
from rules_scala.
There is a ticket for some API to make this work, but I think the java rules don't have a contract like this. I wouldn't want to add preemptively out of anxiety that it would slow down the build by doubling the number of targets, half of which would not be used in scala-only repos (even with mixed java-scala it is not that common to depend across languages).
from rules_scala.
I don't see how to do the java_import
. We can only call native rules from macros, not other skylark rules. But we can't see in a macro all the dependencies we need to add to the java_import.
I think we may just have to wait until bazelbuild/bazel#970 is solved. I can't see any non-manual way to work around this, but maybe I'm missing something.
from rules_scala.
What if we benchmarked preemptively creating java_import
(assuming that actually works)? It may be that perf works fine with double the targets.
from rules_scala.
Sure, that would be fine. I actually don't know how to do it though.
Can you see a way?
On Wednesday, May 25, 2016, Colin Marc [email protected] wrote:
What if we benchmarked preemptively creating java_import (assuming that
actually works)? It may be that perf works fine with double the targets.—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#57 (comment)
P. Oscar Boykin, Ph.D. | http://twitter.com/posco | http://pobox.com/~boykin
from rules_scala.
I think we'd have to give the java_import
the specified name, and then build the library jar as a separate _scalajar
rule or something. I can tool around with it later.
from rules_scala.
So, with the recent merge of correct deploy jars we can just do Java import
of deploy jars, bit that is not a great solution since it hides duplicate
classes on the class path, although they should be identical.
How urgent is this? What if we just hope bazel makes it possible to do Java
interoperability as is being discussed?
On Thursday, May 26, 2016, Colin Marc [email protected] wrote:
I think we'd have to give the java_import the specified name, and then
build the library jar as a separate _scalajar rule or something. I can
tool around with it later.—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#57 (comment)
P. Oscar Boykin, Ph.D. | http://twitter.com/posco | http://pobox.com/~boykin
from rules_scala.
@sdtwigg at the risk of extending our conversation to yet another issue this one seems like the most relevant one about enabling java_*
targets to depend on scala_*
targets. Any update on that?
I thought issue 970 has a bit too much noise so maybe we should continue here for followup which doesn't require the Bazel people.
from rules_scala.
Sorry for the delay here. I was ill over the weekend and have been playing catch-up since then.
There was a slight confusion in getting the necessary reviews from the bazel team but things should be in sync now. Here is what I have so far:
Regarding critical bazel contributions:
https://bazel-review.googlesource.com/#/c/9671/ - This one is critical. Otherwise, you will find it somewhat arbitrary what arguments in a java native rule accept skylark rules. This would make it so that all of the java_library|import|binary accept skylark rules for deps|exports|runtime_deps.
Regarding rules_scala changes:
See sdtwigg@8be3df5 as the minimum viable product for this working. As-is, it does work and is how the main API will ultimately probably look. Preliminary tests indicate it is working fine (especially after the other cleanup PR I did which took care of most of the other oddities that used to be in that commit).
I have not been aggressively pushing to submit due to these two pending bazel contributions:
https://bazel-review.googlesource.com/#/c/9730/ - Changes java_common.create_provider to take depsets instead of lists. API-breaking (for an unpublished, experimental API) that would break my rules_scala changes until they are adjusted. It is a simple adjustment (involving removing the to_list calls!) but still technically breaking.
https://bazel-review.googlesource.com/#/c/9670/ - This cleans things up the implementation and better restricts compile jars. Internally, it means we can just use JavaProvider primarily just like the java rules are using our java provider. Also, cleans up a glitch in current implementation where it is getting transitive compile jars from java rules rather than just the 'local' compile jars.
from rules_scala.
Update with good news: All the referenced changes to bazel have been merged.
from rules_scala.
from rules_scala.
from rules_scala.
@sdtwigg
Any updates? I'm mainly asking since there are some changes I'm thinking about which will probably be easier when this lands
from rules_scala.
Hey,
@sdtwigg I'm sorry to be a nuisance but would you rather someone take sdtwigg@8be3df5 and continue from there?
I don't want to stress you too much but on the other hand I think it would help with a few different issues (junit logs, javac default encoding not being UTF8 and maybe javac default debug symbols)
from rules_scala.
@johnynek this is solved, right?
from rules_scala.
I think so. yes!
from rules_scala.
Related Issues (20)
- Upgrade CI tests to use Bazel 6 HOT 2
- rules_scala cause IJ plugin failures with Bazel@HEAD
- Support for specifying test classes and/or test cases when using junit tests HOT 4
- warning: [path] bad path element
- [Scala 2.13.12] Issue with scala.tools.nsc.reporters.Reporter when compiling
- FYI - Discussion for SIP-51: drop 2.13 library forwards binary compatibility
- rules_scala support for JDK 21 HOT 42
- Add add_opens and add_exports support HOT 1
- Scalafmt fails with Build without the bytes HOT 20
- Support Scala 3.3.1
- SemanticdbInfo.plugin_jar should be File not string HOT 2
- coverage creates the offline.jar into same directory for tests with different directories
- Bazel 7 - scala_proto_aspect rule must declare '@@bazel_tools//tools/jdk:toolchain_type' toolchain in order to use java_common HOT 1
- Can't run a bazel executable within bazel on Windows HOT 10
- javacopts order differs from java_library
- strict_deps_mode = error complains about dependencies that aren't referenced HOT 3
- use newer version of scalafmt
- How to set JVM version? rules_scala keeps insisting on using Java 11 HOT 1
- Unreadable test result
- test_scala_proto_server test is flaky on MacOS CI
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rules_scala.