For managing and starting processes, in Scala we have the package scala.sys.process.
But SBT have nearly all the classes in that package replicated in the sbt package, with slight variations.
E.g. we have scala.sys.process.ProcessBuilder and sbt.ProcessBuilder.
I wonder:
Why this duplication?
Which one should be used?.
I've decided to use the standard Scala package, but don't know if this the best decision. I've checked that it works ok.
It got imported into scala-library as of 2.9.0, see 5bada81.
I've not seen anyone recommend using Scala's Process API over sbt, so I've continued to use sbt's.
Also in one case with both sbt._ and scala.sys.process._ imports present I've seen IntelliJ throw some false positive errors.
Related
If I add the com.google.truth.extensions:truth-proto-extension:1.1 jar to my bazel workspace, it seems to totally nuke the classes from com.google.guava:guava:28.2-jre, resulting in errors like
import static com.google.common.collect.ImmutableMap.toImmutableMap;
^
symbol: static toImmutableMap
location: class ImmutableMap
java/com/google/fhir/protogen/ProtoGenerator.java:316: error: cannot find symbol
.collect(toImmutableMap(def -> def.getId().getValue(), def -> def));
^
symbol: method toImmutableMap((def)->def[...]lue(),(def)->def)
location: class ProtoGenerator
Your documentation says
One warning: Truth depends on the “Android” version of Guava, a subset of the “JRE” version.
If your project uses the JRE version, be aware that your build system might select the Android version instead.
If so, you may see “missing symbol” errors.
The easiest fix is usually to add a direct dependency on the newest JRE version of Guava.
Does this mean anything other than the maven dep on com.google.guava:guava:28.2-jre? If not, what's the next easiest fix?
The key word here is "newest": You'll need to depend on (as of this writing) 30.1-jre. I have edited the docs to emphasize this.
(You can see the newest version in various locations, including: Maven Central, Maven Central Search, the Guava GitHub page.)
The problem is:
Some tools (including Gradle as well as the maven_install rule from Bazel's rules_jvm_external) pick the "newest" version of any given artifact among all versions found in your transitive dependencies.
Truth 1.1 depends on version 30.0-android.
30.0-android is considered to be "newer" than 28.2-jre (because 30 is greater than 28).
The -android releases lack the Java 8 APIs.
(So you can actually fix this by depending on any -jre version from 30.0-jre up: 30.0-jre is considered "newer" than 30.0-android because of alphabetical order. Fun!)
Unfortunately, the Maven ecosystem doesn't support a good way to offer 2 "flavors" of every release (JRE+Android). (People often suggest the Maven "classifier," but that does not actually solve the problem.)
For the future:
Gradle: Gradle is working with us to provide its own solution, but it's not quite ready yet.
Maven: Maven is unlikely to provide help. (It doesn't even try to pick the "newest" version, let alone support "flavors.")
Bazel: I don't know if rules_jvm_external (which uses Coursier) has any plans to support "flavors." (Editorializing a bit: In an ideal world, I would rather specify all my repo's transitive dependencies and their versions myself, rather than having the build system try to work it out for me. That can help avoid surprises like this one. But that brings its own challenges, and we've made only incremental effort toward addressing them in our own Bazel-based projects.)
I just built installed from the Opam package manager, and am trying to learn how to use value analysis from the tutorial on the frama-c website. I'm currently unable to use the builtin.c file, it's not in my share folder and I cannot figure out how to use -val-builtin (if that's even appropriate).
Any ideas on how to get this going?
I installed the 20151002 release of Frama-c.
Thanks for the help!!
Frama-C "semi-builtins" such as Frama_C_interval no longer need an implementation to be analyzed by Value. Hence, most of builtin.c has been removed, and the rest has been inlined in other files. All mentions of builtin.c in the manual can be ignored, provided __fc_builtin.h is included instead. Similarly, builtin.h has been replaced by __fc_builtin.h. (But a warning is emitted to make the user aware of this fact.) We will update the manuals for Frama-C Aluminium to clarify this.
Regarding which version should be used, I strongly advise you to use Magnesium (20151002). There have been quite a few improvements through the years.
I've just started using an sbt plugin for packaging JavaFx/ScalaFx applications sbt-javafx. This under Java 7.
While the plugin seems to work pretty well, it is not able to properly package multi-module project. A workaround they have found is to use exportsJars := true in all the modules on which the JavaFX modules depends on.
I also have IntelliJ IDEA that can produce a JavaFX application for me, though that would break the automated build. I'd very much like to have the executable automated.
I need to understand the broad implication of that parameter on my sbt build. Why is the setting needed to be true?
Here is the help definition:
Determines whether the exported classpath for this project contains classes (false) or a packaged jar (true).
It sounds like by default it's false. Why?
p.s. If someone has a cleaner solution to package JavaFX/ScalaFX applications using sbt, please feel free to share.
I have an sbt project in which the build is normally invoked via package-tar. If a developer types package, it's very likely that they actually meant package-tar instead.
However, package-tar depends on package. How can I prevent or deter or warn when a developer seems to be making this mistake - since I can't actually disable the package task because it's necessary?
I considered integrating actual deployment into the build, but this is not compatible with our current deployment process.
Instead of making package-tar a separate task, how about just redefining package to do what you want? The new behavior can invoke the old behavior.
http://www.scala-sbt.org/0.13.0/docs/Detailed-Topics/Artifacts.html has examples of customizing what package does. The material on addArtifact looks relevant.
I am beginning work on a project that makes heavy use of R. I've used R in the past, but only in a casual mode, whereas I'm now interested in following a more rigid practice of test/source control/continuous integration. I'm hoping to use Gradle with this project if possible, but I can't find any evidence that it is possible to use Gradle with R. Is it possible to create an R project with Gradle, and if so, where can I find steps to help me get started?
There appears to be a third-party plugin (https://github.com/jamiefolson/gradle-plugin-r). Alternatively, if R provides some command-line tools or Ant tasks, you can call into them from Gradle.
We have been working on gradle-R-plugin. (link to source is here https://github.com/arekbee/gradle-R-plugin). We have used it for CI/CD with TeamCity. gradle-R-plugin is base on devtools R package. I am happy to help you with this plugin.