Support mixed scala/java targets about rules_scala HOT 9 CLOSED

for mixed single targets we need this:
http://www.codecommit.com/blog/scala/joint-compilation-of-scala-and-java-sources

from rules_scala.

any plans for this?
I work with @barlevalon (who opened the issue in bazel) and I'll probably be trying to tackle it in the next few days following the link @johnynek added here.
If there are objections or tips I'd love to hear them

from rules_scala.

I'm happy to review and merge code here, but I really don't need joint scala/java targets.

(I find that scalac by itself is slow enough that I really try to keep targets very small, that said, old projects might be easier to build with this if we have this capability).

from rules_scala.

Awesome, thanks!

For us it's really mandatory since our codebase has really evolved side by
side and many of our core projects still contain Java "pockets".

Any tips?
My current direction is to add a joint_scala_java method similar to
scala_library which will be similar to the existing scala_library but will
run scalac and javac like in the article above.
Does that sound good? If so I'll drill down.
On יום ב׳, 23 במאי 2016 at 7:18 P. Oscar Boykin [email protected]
wrote:

I'm happy to review and merge code here, but I really don't need joint
scala/java targets.

(I find that scalac by itself is slow enough that I really try to keep
targets very small, that said, old projects might be easier to build with
this if we have this capability).

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#26 (comment)

from rules_scala.

I think ideally, we would just use scala_library and scala_binary and use a filetype filter to select the .java and .scala sources. Then the work flow is identical except that we also accept some java files. I would error if there is not at least one .scala file in the sources, however.

As a test, you might first make a totally separate rule as you suggest, but my guess is there will be a lot of duplication.

from rules_scala.

👍🏽
On יום ב׳, 23 במאי 2016 at 20:39 P. Oscar Boykin [email protected]
wrote:

I think ideally, we would just use scala_library and scala_binary and use
a filetype filter to select the .java and .scala sources. Then the work
flow is identical except that we also accept some java files. I would error
if there is not at least one .scala file in the sources, however.

As a test, you might first make a totally separate rule as you suggest,
but my guess is there will be a lot of duplication.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#26 (comment)

from rules_scala.

@johnynek I've started fiddling around and indeed got the scala compiler to compile with very small changes like you suggested.
I'm a bit stuck on how to invoke the java compiler so that the resulting jar will contain all the needed .class files.
I've asked in bazel-discuss but I'll use this platform also if that's ok to ask you: It seems to me that I need to run the javac in _compile after scalac runs but I don't know how to invoke multiple actions in the same rule. Any pointers? Thanks!

from rules_scala.

update: brian silverman helped me in discuss by pointing me to macros.
Current direction (which I don't really like) is to have a macro which will call:
scala_library(java+scala) and then scala_export_to_java and then native.java_library(java)
Problem is I'm getting syntax error at 'scala_export_to_java': expected newline. and I have no idea how to resolve it. I've tried fiddling with the line endings and the indentation but no dice.

from rules_scala.

I think this issue is closed now. Please reopen if the current solution has issues.

from rules_scala.