Giter VIP home page Giter VIP logo

rules_scala's Issues

```bazel run``` broken with 0.2.3

Haven't had time to look at this so if anyone has:
With bazel 0.2.3:

~/hello_world.scala git:master ❯❯❯ bazel build app
INFO: Found 1 target...
Target //:app up-to-date:
  bazel-bin/app
INFO: Elapsed time: 26.085s, Critical Path: 1.79s
~/hello_world.scala git:master ❯❯❯ bazel run app
INFO: Found 1 target...
Target //:app up-to-date:
  bazel-bin/app
INFO: Elapsed time: 0.467s, Critical Path: 0.00s

INFO: Running command line: bazel-bin/app
/private/var/tmp/_bazel_smparkes/08fe4a003be085753c237916361d8505/hello_world.scala/bazel-out/local-fastbuild/bin/app: line 3: /private/var/tmp/_bazel_smparkes/08fe4a003be085753c237916361d8505/hello_world.scala/bazel-out/local-fastbuild/bin/app.runfiles/external/local_jdk/bin/java: No such file or directory
ERROR: Non-zero return code '127' from command: Process exited with status 127.
./7e7209a62ba3a685a6bd98b8dbd655ea/scala/bazel-out/local-fastbuild/bin/app.runfiles/__main__/external/local_jdk/bin/java

and

./7e7209a62ba3a685a6bd98b8dbd655ea/scala/bazel-out/local-fastbuild/bin/app.runfiles/local_jdk/bin/java

exist but

/private/var/tmp/_bazel_smparkes/08fe4a003be085753c237916361d8505/hello_world.scala/bazel-out/local-fastbuild/bin/app.runfiles/external/local_jdk/bin/java

does not

Build is not identical when scala rules compile java sources

See example failures in #101 #106

This seems to only happen on linux. The most common reason is that somehow a timestamp is making it into an output file. We should be able to check by looking at the binary diff to find the actual difference.

We need to fix this because we can't merge a test that makes the build go red, but at the same time, this means currently when using mixed scala/java targets on linux, you will not have optimal caching (each upstream rebuild will invalidate everything downstream).

build a rule to generate the intra-target source deps

Zinc:
https://github.com/typesafehub/zinc

could analyze sources and output the dependency graph of the files in a target. This could be helpful to output a set of targets that are smaller so the bazel's built in incrementalism is more effective.

so, you could have something like this:

scala_file_dependencies(name = "foo", target = "mylibrary")

and this could generate a new BUILD as output that has each file as a target with the correct dependencies.

This seems suboptimal for usability, but given bazel's model of compilation as a pure function from source to output artifact, this might part of a practical solution for making faster builds.

how to configure compiler plugins?

I am thinking that commonly, you might want a compiler plugin for the whole repo.

We might want to have something like scala_library_internal so then repos can make a local scala_library macro that sets up default compiler options.

That seems like it would work okay. Any better approach?

I don't know now namespacing works in skylark, but I assume I can't import a rule with a name foo and also define a rule with the same name (thus the work around of adding variants of _internal to all the rules so we can import just a few of those).

Improve scala to java exports

See: #56 (comment)

one idea could be to improve this:

https://github.com/bazelbuild/rules_scala/blob/master/scala/scala.bzl#L490

so it is a skylark rule, not a macro, that consumes targets and looks at their runtime and compile-time jars, and just exports them (right now it is not saving much effort).

Then, that could be used to test this feature. I'll add an issue.

the fix we added for #18 is still pretty mechanical: you pass output jar names. What we really want is to just list targets and get all their exports and runtime deps for use from java.

In this way, we can test that the runtime paths are correct without conflating with scala_binary.

Cross building

So this isn't anything urgent but popped into my head and thought it would be best to start the conversation now before 2.12 is released and we might have more pressure.
2 questions:

  1. How to parameterize the rule with respect to scala version? (don't think it's complicated but haven't looked into it).
  2. How to cross build a target to both 2.11 and 2.12 like sbt supports. This is useful for both rolling out the upgrade in an organization and for OSS libraries.

Support different versions of scala

users should easily be able to use a particular major version of scala.

Two approaches:

  1. each tag/commit only supports one and users pick.
  2. have scala_2_10.bzl, scala_2_11.bzl etc... Hopefully they can share code and the external repositories work just fine.

Ensime support

I was wondering if there is any simple way of adding support for ensime? As reference, the following link references support for other build tools for it: [http://ensime.github.io/build_tools/](Ensime build tools).

test_run should be a sh_test

This would allow to test it with bazel test

To do so, shipping the source of the repository might be needed. See how it is done in bazel in src/test/shell/bazel/...

add support for src jars

for code gen, such as scrooge, we probably want to create src jars, then reuse the existing scala rules. Right now we require .scala files as source.

I guess this would use find after we unjar to make sure all the files can be handled.

specs2 support

Hi,
Most of our tests use specs2 (a small portion uses JUnit and a handful use scalatest).
Do you think specs2 support should be part of this library?
If so do you think it should be via a flag to scala_test? via an additional rule?
Not sure I like the fact that scalatest is always on the classpath even if I don't need it but might be negligible.

I can add this support in an external repo but I think it's more natural for it to reside here.

Scrooge --finagle

Is it possible to generate finagle services with current scrooge support? (like passing --finagle in sbt plugin)

support plugins on scala_library

The scala_library rule doesn't support the plugins attribute. Needed for things like the auto-service plugin which facilitates ServiceLoaders, e.g., to configure logback.

don't depend on all of bazel to get the worker API

The worker API uses protobufs that are housed in the bazel repo. As a result, to build that worker process we need to pull all of bazel.

We should either copy the protobufs and build our own client, or copy the generated java code and build that.

test_run script doesn't clean hash outputs and doesn't really work on osx vanilla

Hi,
AFAIU OS X has md5 and not md5sum which is why I get ./test_run.sh: line 25: md5sum: command not found when running the script. Don't know if you want this to run on local contributors machines but if it's not important to you maybe it should be noted.
Second problem is that the hash1/hash2 files aren't deleted and aren't ignored.
Sounds to me like they should be deleted if the diff says they're the same. In any case ignoring them could also solve the problem although being a bit more hacky.
One last option is to maybe write them to bazel-out which is currently ignored.

What would you like to do with this issue?

General scrooge performance

Right now, the code generator is not as performant as it could be... of course, this is mainly with antipatterns (a ton of thrifts which depend on a ton of thrifts) that hopefully bazel will prevent, but which exist at many companies which heavily use thrift. There is a lot of work that could be done to make this maximally performant... some ideas

  • Make scrooge imports jars #44
  • Use the full graph of srcjars/thrift jars to minimize the number of times we extract jars
  • ??? (there are scrooge changes that could also probably better support this... such as keeping around some intermediate data or something, but at that point maybe we just want smaller targets...)

REPL support

I don't think that bazel has any notion a repl, but I can imagine adding macro like

scala_repl(name = "foo", deps = [":a", ":b"])

which will create a repl with the classpath given by the runtime dependencies of :a, :b.

Actually, remembering terminal pains, the easiest thing might be to do a real skylark rule with scala in the scala-sdk, or perhaps use ammonite: http://www.lihaoyi.com/Ammonite/#Features

Possible confusion in the docs //scala:scala.bzl vs @io_bazel_rules_scala//scala:scala.bzl

First of all thanks a lot for all your hard work, it's really appreciated!

I'm not sure this is in the scope of this repo but the fact of the matter is that I went along the readme and since it mentions the load with respect to prelude_bazel I wasn't sure if there isn't a different syntax for that use-case.
I went to the tests since they are the executable specification and failed since they use the absolute(?) path //scala:scala.bzl
This is an on-boarding issue since if I was familiar with Bazel syntax well enough I wouldn't have made that mistake but I think we want to make on-boarding easier.
2 options I had in mind:

  1. Add a note in the readme at the end of the overview explaining the difference
  2. Add a scala app to the bazelbuild/examples repo
    The added value of #2 is that it serves as a bit of a test application since it has to use the syntax like "regular" users.

I'd be happy to contribute both options but didn't want to barge in with a PR before we discuss it.

scala_binary _deploy.jar target is not flattened

The goal of the _deploy.jar targets is that they are self-contained, that they can be executed with
java -jar X_deploy.jar
The current _deploy.jar target looks to be identical to the non-_deploy.jar target.

improve remote tests

see: #83

we need to have tests that verify that the rules work when using targets in remote repos. The testing is not clear there.

I think we need to set up two test WORKSPACES:

  1. depends on the rules and defines some thrift/scala targets.
  2. second repo depends on the first, and consumes some thrift classes from the target in 1.

Support for Scala.js

Scala.js http://www.scala-js.org/ has been very popular in Scala community. At work we are having a very large code base in both Scala (backend) and Scala.js (frontend). I am wondering if anyone has tried to compile scala.js using bazel?

Fatal compilation error when using scala-pickles/boopickle libraries (probably macros-related)

Environment:

Ubuntu 16.04

bazel version 
Build label: 0.4.3rc6
Build target: bazel-out/local-fastbuild/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Wed Dec 21 15:53:43 2016 (1482335623)
Build timestamp: 1482335623
Build timestamp as int: 1482335623

In WORKSPACE:

git_repository(
    name = "io_bazel",
    remote = "git://github.com/bazelbuild/bazel.git",
    tag = "0.4.3",
)
git_repository(
    name = "io_bazel_rules_scala",
    remote = "https://github.com/bazelbuild/rules_scala.git",
    commit = "4f3fc159d64711f2b28d18b507cfe25c3348e4d5",
)
load("@io_bazel_rules_scala//scala:scala.bzl", "scala_repositories")
scala_repositories()

maven_jar(
    name = "me_chrons_boopickle_2_11",
    artifact = "me.chrons:boopickle_2.11:1.2.4",
)

In third_party/BUILD:

java_library(
    name = "me_chrons_boopickle_2_11",
    visibility = ["//visibility:public"],
    exports = [
        "@me_chrons_boopickle_2_11//jar",
    ],
)

SimpleCaseClass.scala:

package com.komanov.bazeltest

import boopickle.Default._

case class SimpleCaseClass(name: String)

object SimpleCaseClass {
  override def toByteArray(s: SimpleCaseClass) = {
    Pickle.intoBytes(s)
  }
}

Its BUILD file:

scala_library(
    name = "bazeltest",
    srcs = ["SimpleCaseClass.scala"],
    deps = ["//third_party:me_chrons_boopickle_2_11"],
)

When I try to build it:

bazel build --verbose_failures --worker_verbose //src/com/komanov/bazeltest
INFO: Found 1 target...
WARNING: Scalac worker (id 39) can no longer be used, because its process terminated itself or got killed.
INFO: Destroying Scalac worker (id 39)
INFO: Created new non-sandboxed Scalac worker (id 40), logging to .../.cache/bazel/_bazel_user/8284de460f2a76fffe4edd44c16c874d/bazel-workers/worker-40-Scalac.log
ERROR: .../src/com/komanov/bazeltest/BUILD:1:1: scala //src/com/komanov/bazeltest:bazeltest failed: Worker process did not return a correct WorkResponse. This is probably caused by a bug in the worker, writing unexpected other data to stdout.
Target //src/com/komanov/bazeltest:bazeltest failed to build
INFO: Elapsed time: 2.200s, Critical Path: 2.09s

worker-40-Scalac.log.txt

Looks like macros expansion related (non-macros code is working fine with this library).

we should create a single xml output

Issue with compiling multiple Java Source files

Hey Guys,

I've been trying to use scala_library to compile a mixture of both scala and java files. It seems the java file compilation fails when there are multiple java files. Up on looking at the error, it seems that the javac command that we invoke is taking the list of files as a single string block instead of taking it as a separate files. Below is the error that im getting while invoking javac

javac: file not found: infra/BetterOutput.java infra/Changeset.java infra/CompilationException.java
Usage: javac <options> <source files>
use -help for a list of possible options
Exception in thread "main" java.lang.RuntimeException: nope
	at io.bazel.rulesscala.scalac.ScalaCInvoker.main(ScalaCInvoker.java:345)
Caused by: java.lang.RuntimeException: javac process failed!
	at io.bazel.rulesscala.scalac.ScalaCInvoker.compileJavaSources(ScalaCInvoker.java:303)
	at io.bazel.rulesscala.scalac.ScalaCInvoker.processRequest(ScalaCInvoker.java:238)
	at io.bazel.rulesscala.scalac.ScalaCInvoker.main(ScalaCInvoker.java:341)
Target //infrastructure:infra-scala failed to build

Simplest fix was to append the file names directly to the command and that seems to be working fine

diff --git a/src/java/io/bazel/rulesscala/scalac/ScalaCInvoker.java b/src/java/io/bazel/rulesscala/scalac/ScalaCInvoker.java
index 4c64c2c..4208123 100644
--- a/src/java/io/bazel/rulesscala/scalac/ScalaCInvoker.java
+++ b/src/java/io/bazel/rulesscala/scalac/ScalaCInvoker.java
@@ -281,19 +281,13 @@ public class ScalaCInvoker {
       commandParts.add(ops.javacOpts);
     }

-    StringBuilder files = new StringBuilder();
-    int cnt = 0;
-    for(String javaFile : ops.javaFiles) {
-      if (cnt > 0) files.append(" ");
-      files.append(javaFile);
-      cnt += 1;
-    }
-
     commandParts.add("-classpath");
     commandParts.add(ops.classpath + ":" + tmpPath.toString());
     commandParts.add("-d");
     commandParts.add(tmpPath.toString());
-    commandParts.add(files.toString());
+    for(String javaFile : ops.javaFiles) {
+      commandParts.add(javaFile.toString());
+    }

     Process iostat = new ProcessBuilder(commandParts)
       .inheritIO()

Not sure if anyone has seen this behaviour when using multiple java source files. My BUILD file is pretty simple,

package(default_visibility = ["//visibility:public"])

load("@io_bazel_rules_scala//scala:scala.bzl", "scala_library", "scala_binary", "scala_export_to_java")

scala_library(
    name = "infra-scala",
    srcs = glob([
        "*.scala",
        "*.java",
    ], exclude = ["TestError.java"]),
    deps = [
        "//third_party/jar:mvnrepo",
    ],
)

Problem building with bazel 0.3.2

From bazelbuild/bazel#1967 (comment) and continued here:

@damienmg - yesterday, @dinowernli and I tried it on his ubuntu workstation, and got

ERROR: /home/dino/Private/code/everything/ArchUtil/src/main/java/improbable/archutil/testing/BUILD:7:1: scala //ArchUtil/src/main/java/improbable/archutil/testing:testing_scala failed: linux-sandbox failed: error executing command /home/dino/.cache/bazel/_bazel_dino/8d44bf8f062af3067a03c8a57a9b5ad0/execroot/everything/_bin/linux-sandbox ... (remaining 4 argument(s) skipped).
Exception in thread "main" java.lang.RuntimeException: nope
    at io.bazel.rulesscala.scalac.ScalaCInvoker.main(ScalaCInvoker.java:338)
Caused by: java.io.IOException: Cannot run program "external/local_jdk/bin/javac ": error=2, No such file or directory
    at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
    at io.bazel.rulesscala.scalac.ScalaCInvoker.compileJavaSources(ScalaCInvoker.java:293)
    at io.bazel.rulesscala.scalac.ScalaCInvoker.processRequest(ScalaCInvoker.java:237)
    at io.bazel.rulesscala.scalac.ScalaCInvoker.main(ScalaCInvoker.java:334)
Caused by: java.io.IOException: error=2, No such file or directory
    at java.lang.UNIXProcess.forkAndExec(Native Method)
    at java.lang.UNIXProcess.<init>(UNIXProcess.java:248)
    at java.lang.ProcessImpl.start(ProcessImpl.java:134)
    at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
    ... 3 more

The BUILD file is:

package(
    default_visibility = ["//visibility:public"],
)

load("@io_bazel_rules_scala//scala:scala.bzl", "scala_export_to_java")

scala_library(
    name = "testing_scala",
    testonly = 1,
    srcs = glob(["*.java"]),
    visibility = ["//visibility:private"],
    deps = [
        "//third_party/scalatest",
    ],
)

scala_export_to_java(
    name = "testing",
    exports = [":testing_scala"],
    runtime_deps = [],
)

There is a single java source file in the package:

package improbable.archutil.testing;

import org.scalatest.TagAnnotation;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

/**
 * Adds a scalatest "tag" to a test which he have configured at top-level to be excluded from the
 * sbt test runs.
 */
@TagAnnotation
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface ExcludeInSbt {
}

Excerpts from WORKSPACE that I think are pertinent

# Import Bazel's scala build rules.
git_repository(
    name = "io_bazel_rules_scala",
    remote = "https://github.com/petemounce/rules_scala.git",
    commit = "c2c878db5caa42c65f717b72511530cfb4f39294",
)
git_repository(
    name = "io_bazel",
    remote = "git://github.com/bazelbuild/bazel.git",
    tag = "0.3.2",
)
load("@io_bazel_rules_scala//scala:scala.bzl", "scala_repositories", "scala_mvn_artifact", "scala_version")
scala_repositories()

(we tried with tag=0.3.1 and bazel 0.3.1 as well)

The sha that the io_bazel_rules_scala is pointed at is to my fork; we have our own fork of rules_scala that we point at and periodically keep in sync with upstream, and that's what I'm currently trying to do at the same time as updating us to bazel 0.3.2.

Add support for tut documentation

Tut allows us to embed scala code in markdown files, and then run the compiler on that code so our docs don't get stale.

See: https://github.com/tpolecat/tut

An example of running at the command line can be seen here:

https://github.com/tpolecat/cbt/blob/80b6409c664d48dd5aa604b3d2ee100dad9bf4cf/build/build.scala#L26-L31

it should be pretty easy to add a tut_doc rule that has a single .md source and produces a single _tut.md output, or a rule that creates a _tut.zip of several sources (since bazel rule output has to be statically known from the build file).

/cc @tpolecat

Why does test_disappearing_class appear twice in test_run.sh

Hi,
run_test test_disappearing_class appears twice in the test_run.sh script, is this on purpose? If so why? Additionally do you think a comment might be helpful because for me it was confusing since I thought this might be a bug.

Additionally,
Is there an open issue to track converting test_run.sh to a "proper" bazel test run? I know it's not high on your priority but maybe if it's open someone will grab it.

md5sum hashes do not match when you build the same code twice on macos

Just discovered this recently since I was working on build caching, but it seems like the default scala rule here do not build jars with the same hash on two separate runs with the same inputs. This seems to break the caching code in bazel that gets a digest with md5.
This is what I ran on this repo here:

bazel build test/... 
md5 bazel-bin/test/*.jar > hash
bazel clean
bazel build test/... 
md5 bazel-bin/test/*.jar > hash2

When you diff the two files it shows that all the jars have different hashes. even the ijars.

Xins-MacBook-Pro:rules_scala xinlu$ diff hash hash2
1,3c1,3
< MD5 (bazel-bin/test/ExportOnly_deploy.jar) = e513f71cb2024bf2a5c6ac0a0208fb5e
< MD5 (bazel-bin/test/ExportOnly_ijar.jar) = e513f71cb2024bf2a5c6ac0a0208fb5e
< MD5 (bazel-bin/test/Exported_deploy.jar) = 4e1b1b620a002219a2edda47dc9a9cd2

---
> MD5 (bazel-bin/test/ExportOnly_deploy.jar) = 764d68cad512ea85baf75aec623c465e
> MD5 (bazel-bin/test/ExportOnly_ijar.jar) = 764d68cad512ea85baf75aec623c465e
> MD5 (bazel-bin/test/Exported_deploy.jar) = 31ea9c77a3bbf21d2b0ffc6def3247e4
5,6c5,6
< MD5 (bazel-bin/test/HelloLibTest_deploy.jar) = 1faf15bba18d60a4d9fee7937f3d18d6
< MD5 (bazel-bin/test/HelloLib_deploy.jar) = d72085331bdb480df424be08c0b8b5bd

---
> MD5 (bazel-bin/test/HelloLibTest_deploy.jar) = 9822c828fc3a1cbb87dbcd3800ba9e62
> MD5 (bazel-bin/test/HelloLib_deploy.jar) = 398401f2f02554b2d60aa62288cb255f
10,11c10,11
< MD5 (bazel-bin/test/MacroTest_deploy.jar) = 8c4767eead2843d79b850e56c86ea42e
< MD5 (bazel-bin/test/OtherLib_deploy.jar) = 2fc708e492140ed78ff0a489df106dcd

---
> MD5 (bazel-bin/test/MacroTest_deploy.jar) = 8024d3769157936d4777fe21aa88c25e
> MD5 (bazel-bin/test/OtherLib_deploy.jar) = be1812ca6d4eda50fdbb0bf340b088c8
13c13
< MD5 (bazel-bin/test/Runtime_deploy.jar) = fffa4662d3403c7a2daa042154e03f8f

---
> MD5 (bazel-bin/test/Runtime_deploy.jar) = efea7e4838f6bcd8582a0a5d86ca38f8
15,17c15,17
< MD5 (bazel-bin/test/ScalaBinary_deploy.jar) = 75871f3e5ef7addcbbfad04fe813b87a
< MD5 (bazel-bin/test/ScalaLibBinary_deploy.jar) = c46c0b69cdea700f37b40ceeb6b0bdd6
< MD5 (bazel-bin/test/ScalaLibResources_deploy.jar) = 4c0d57f5ad553e91f83f8b8bc866a195

---
> MD5 (bazel-bin/test/ScalaBinary_deploy.jar) = 4d9d183d54111532a7b88067d6e4572d
> MD5 (bazel-bin/test/ScalaLibBinary_deploy.jar) = 79684af04f1f3fa6b581775611b05aac
> MD5 (bazel-bin/test/ScalaLibResources_deploy.jar) = ea4157e3f8f2e59587bddbd26999bd89
19c19
< MD5 (bazel-bin/test/a_deploy.jar) = 08fe25daf5678fe3e1d43bc52c88daf5

---
> MD5 (bazel-bin/test/a_deploy.jar) = 5f071b2165bd91ff1fee97b5409cf282
21,25c21,25
< MD5 (bazel-bin/test/b_deploy.jar) = e513f71cb2024bf2a5c6ac0a0208fb5e
< MD5 (bazel-bin/test/b_ijar.jar) = e513f71cb2024bf2a5c6ac0a0208fb5e
< MD5 (bazel-bin/test/c_deploy.jar) = e513f71cb2024bf2a5c6ac0a0208fb5e
< MD5 (bazel-bin/test/c_ijar.jar) = e513f71cb2024bf2a5c6ac0a0208fb5e
< MD5 (bazel-bin/test/d_deploy.jar) = ecb50527b59a959320496d20809276bc

---
> MD5 (bazel-bin/test/b_deploy.jar) = 764d68cad512ea85baf75aec623c465e
> MD5 (bazel-bin/test/b_ijar.jar) = 764d68cad512ea85baf75aec623c465e
> MD5 (bazel-bin/test/c_deploy.jar) = 764d68cad512ea85baf75aec623c465e
> MD5 (bazel-bin/test/c_ijar.jar) = 764d68cad512ea85baf75aec623c465e
> MD5 (bazel-bin/test/d_deploy.jar) = 9bbe26c787071564c34af4cd418f7b9d
27,28c27,28
< MD5 (bazel-bin/test/jar_export_deploy.jar) = e513f71cb2024bf2a5c6ac0a0208fb5e
< MD5 (bazel-bin/test/jar_export_ijar.jar) = e513f71cb2024bf2a5c6ac0a0208fb5e

---
> MD5 (bazel-bin/test/jar_export_deploy.jar) = 764d68cad512ea85baf75aec623c465e
> MD5 (bazel-bin/test/jar_export_ijar.jar) = 764d68cad512ea85baf75aec623c465e

---

I think this is because the jar command used by the scala.bzl rule changes the timestamp of the Manifest file even if you touch it. Example:


Xins-MacBook-Pro:rules_scala xinlu$ unzip -l bazel-bin/test/ExportOnly_deploy.jar
Archive:  bazel-bin/test/ExportOnly_deploy.jar
  Length     Date   Time    Name
 --------    ----   ----    ----
        0  05-18-16 13:58   META-INF/
      118  05-18-16 13:58   META-INF/MANIFEST.MF
 --------                   -------
      118                   2 files

Basically this means that the touch to set the timestamp to 1980 didn't matter.
In our own internal version I changed the jarring to zip -X -q -FS since -FS keeps timestamps and now the hash is the same between two different builds that have the same inputs because the timestamps match.

Also this seems to be on mac, and not linux. The hashes seem to be okay on linux, but a lot of our devs use macs and it actually breaks their local cache.

add support for scrooge thrift generator

See: http://twitter.github.io/scrooge/CommandLine.html

something basic can be done probably with a genrule + a macro once we solve #2.

An problem (to me) is dealing with dependencies between thrift targets. One approach is to pull the transitive thrift files, compile all of them using --gen-file-map, then only put the output classes from the current target into the current jar. This may be too slow for deep dependencies however.

ci.bazel.io build is broken

Broken by PR #29. See http://ci.bazel.io/job/rules_scala/105/

Linux (with sandboxing):

____From making thrift archive //test/src/main/scala/scala/test/twitter_scrooge/thrift:thrift:
external/local_jdk/bin/jar: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
external/local_jdk/bin/jar: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
ERROR: /home/ci/workspace/rules_scala/BAZEL_VERSION/HEAD/PLATFORM_NAME/linux-x86_64/test/src/main/scala/scala/test/twitter_scrooge/thrift/BUILD:3:1: output 'test/src/main/scala/scala/test/twitter_scrooge/thrift/libthrift.jar' was not created.
ERROR: /home/ci/workspace/rules_scala/BAZEL_VERSION/HEAD/PLATFORM_NAME/linux-x86_64/test/src/main/scala/scala/test/twitter_scrooge/thrift/BUILD:3:1: not all outputs were created.
ERROR: /home/ci/workspace/rules_scala/BAZEL_VERSION/HEAD/PLATFORM_NAME/linux-x86_64/test/src/main/scala/scala/test/twitter_scrooge/thrift/thrift2/thrift3/BUILD:3:1: output 'test/src/main/scala/scala/test/twitter_scrooge/thrift/thrift2/thrift3/libthrift3.jar' was not created.
ERROR: /home/ci/workspace/rules_scala/BAZEL_VERSION/HEAD/PLATFORM_NAME/linux-x86_64/test/src/main/scala/scala/test/twitter_scrooge/thrift/thrift2/BUILD:3:1: output 'test/src/main/scala/scala/test/twitter_scrooge/thrift/thrift2/libthrift2_a.jar' was not created.

OS X:

ERROR: /Users/ci/workspace/rules_scala/BAZEL_VERSION/HEAD/PLATFORM_NAME/darwin-x86_64/test/src/main/scala/scala/test/twitter_scrooge/BUILD:4:1: creating scrooge files //test/src/main/scala/scala/test/twitter_scrooge:scrooge1_srcjar failed: generator failed: error executing command 
  (cd /private/var/tmp/_bazel_ci/ac44d3454b4099e3ebd2d39821cf0e13/darwin-x86_64 && \
  exec env - \
  bazel-out/local-fastbuild/bin/src/scala/scripts/generator bazel-out/local-fastbuild/bin/test/src/main/scala/scala/test/twitter_scrooge/test/src/main/scala/scala/test/twitter_scrooge/libscrooge1_srcjar.srcjar_only_transitive_thrift_srcs bazel-out/local-fastbuild/bin/test/src/main/scala/scala/test/twitter_scrooge/test/src/main/scala/scala/test/twitter_scrooge/libscrooge1_srcjar.srcjar_immediate_thrift_srcs bazel-out/local-fastbuild/bin/test/src/main/scala/scala/test/twitter_scrooge/libscrooge1_srcjar.srcjar bazel-out/local-fastbuild/bin/test/src/main/scala/scala/test/twitter_scrooge/test/src/main/scala/scala/test/twitter_scrooge/libscrooge1_srcjar.srcjar_remote_jars): com.google.devtools.build.lib.shell.BadExitStatusException: Process exited with status 127.
bazel-out/local-fastbuild/bin/src/scala/scripts/generator: line 3: bazel-out/local-fastbuild/bin/src/scala/scripts/generator.runfiles/external/local_jdk/bin/java: No such file or directory

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.