I have two scala projects, one is already defined to build its docker container through the sbt docker plugin. The other one I want to dockerify as well.
The working one has in its build.sbt the following lines relevant to the docker config:
organization := "com.namespace"
name := "dockerized-app"
version := sys.env.getOrElse("PIPELINE_VERSION", "0.1.0_local")
scalaVersion := "2.12.4"
enablePlugins(JavaAppPackaging)
enablePlugins(DockerPlugin)
packageName in Docker := packageName.value
dockerRepository := Some("our-docker.io:5001")
dockerExposedPorts := Seq(8080)
I thought that I could copy paste the relevant lines to the new project, change the name, and make it work.
Yet when I add the line to the about to be dockerified scala project:
enablePlugins(DockerPlugin)
I get the error:
Cannot resolve symbol DockerPlugin
I've looked through the prexisting projects libraryDependencies, yet it doesn't seem to be configured that way. In the the pre-configured project, IntellJ somehow knows the plugin, I can track that the DockerPlugin comes from com.typesafe.sbt.packager.docker. This made me assume that sbt comes shipped with it by default.
Yet apparently I have to activate it somehow.
Digging deeper I also tried adding this to my plugins.sbt to no avail:
addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "1.3.2")
How to activate DockerPlugin using sbt in scala?
In order to make it working properly you need to add the following line:
addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "1.3.2")
in your project/plugins.sbt file.
Then refresh your project and it should work.
For further information, please check the Sbt Native Packager documentation.
Related
I stumbled upon this Akka grpc tutorial which suggests that we can create a jar from a project that has .proto file under src/main/proto and add it as a dependency in client and server projects to build their respective stubs.
libraryDependencies += "com.example" %% "my-grpc-service" % "1.0.0" % "protobuf-src"
But this doesn't seem to work!! Are there any example projects that demonstrates how this would work in action? How can we externalize protobuf sources and use the same in a jvm based project?
I was able to figure out how to externalise protobuf files properly as per suggestion from akka-grpc docs.
The problem was that I was not adding sbt-akka-grpc plugin required by sbt to recognise .proto files and include them in the packaged jar. Without this plugin there won't be any .proto file made available in the packaged jar.
addSbtPlugin("com.lightbend.akka.grpc" % "sbt-akka-grpc" % "1.1.0")
Make sure to add organization settings in your build.sbt to prepare jar correctly.
organization := "com.iamsmkr"
Also, if you wish to cross-compile this jar to multiple versions add following entries in your build.sbt:
scalaVersion := "2.13.3"
crossScalaVersions := Seq(scalaVersion.value, "2.12.14")
and then to publish:
$ sbt +publishLocal
With appropriate jars published you can now add them as dependencies in your client and server projects like so:
libraryDependencies +=
"com.iamsmkr" %% "prime-protobuf" % protobufSourceVersion % "protobuf-src"
You can check out this project I am working on to see this in action.
Alternate Way
An alternate way I figured is that you can keep your .proto files in a root directory and then refer them in client and server build.sbt like so:
PB.protoSources.in(Compile) := Seq(sourceDirectory.value / ".." / ".." / "proto")
Checkout this project to see it in action.
Searching for examples of library use I downloaded this project.
https://github.com/marcusatbang/Hooks
I then moved the build.bat up one directory. Commented out the xsbt-gpg dependency lines in build.sbt and Build.scala since sbt couldn't find the package. I checked the source to comment out any imports of xsbt-gpg -- there were none. ( Surprise! )
So I managed to compile the project. I then did sbt publish-local. find ~/.ivy2 -iname "\*hooks*jar" generated the following line: .ivy2/local/cc.minotaur/hooks_2.9.0/0.1/jars/hooks_2.9.0.jar.
I then entered the examples folder and tried to build the example project.
The build.scala contains the line: libraryDependencies += "cc.minotaur" %% "hooks" % "0.1", and it generates the error: unresolved dependency: cc.minotaur#hooks_2.9.1;0.1: not found
So how do I fix this error? It seems to me it should be finding the hooks jar/
That could be that your resolver doesn't see local directory. Try something like:
val ivyLocal = Resolver.file("local", file(Path.userHome.absolutePath +
"/.ivy2/local"))(Resolver.ivyStylePatterns)
externalResolvers += ivyLocal
It seems to me that you are using two versions of Scala. The one you are generating the jar is 2.9.0 while the one you are using in the example project is 2.9.1. Probably will solve the problem setting the same version in both projects.
I think your scala version is 2.9.1, u have generated jar for version 2.9.0
change your library dependency as mentioned below.
libraryDependencies += "cc.minotaur" % "hooks_2.9.0" % "0.1"
or add scalaVersion := "2.9.0" in your build.sbt file
sbt (0.13.8) is failing to resolve the dependency in the following extremely simple build.sbt:
organization := "edu.umass.cs.iesl"
name := "nn-depparse"
version := "0.1-SNAPSHOT"
scalaVersion := "2.11.7"
resolvers += "IESL snapshot repository" at "https://dev-iesl.cs.umass.edu/nexus/content/repositories/snapshots/"
libraryDependencies += "cc.factorie" %% "factorie" % "1.2-SNAPSHOT"
parallelExecution := true
For some reason it resolves the following path:
https://dev-iesl.cs.umass.edu/nexus/content/repositories/snapshots/cc/factorie/factorie_2.11/1.2-SNAPSHOT/factorie_2.11-1.2-20151007.170205-28.${package.type}
Rather than the correct path to the jar:
https://dev-iesl.cs.umass.edu/nexus/content/repositories/snapshots/cc/factorie/factorie_2.11/1.2-SNAPSHOT/factorie_2.11-1.2-20151007.170205-28.jar
It seems as though ${package.type} is being interpreted as a literal file extension rather than whatever the contents of the variable package.type, but I have no idea why; I am using the simplest possible build configuration! As far as I know, I don't have any weird sbt configurations lying around (or any at all -- I checked ~/.sbt, and I have tried running on multiple machines).
As #kawty says it does look like the pom in question is malformed, but in terms of fixing your sbt script, you can change you dependency line to:
libraryDependencies += "cc.factorie" %% "factorie" % "1.2-SNAPSHOT" artifacts( Artifact("factorie", "", "jar"))
to manually specify the extension of the artifact that you want.
A following line found in factorie_2.11-1.2-20151007.170205-28.pom:
<packaging>${package.type}</packaging>
I suppose sbt uses this setting to get the artifact.
In the previous .pom file, it has:
<packaging>jar</packaging>
So, maybe it's a broken build.
I am trying a very simple sbt example; when I compile it with sbt, and always get the following error:
org.scala-sbt#sbt_2.9.1;0.12.3: not found
I found a build.properties file under project folder, where I could change the 0.12.3 part; for example, after I changed it to 0.11.3, it will succeed until another inompatible issue; However, I want to know how to change sbt_2.9.1 to, say, sbt_2.9.2; I don't find a configuration file, and even I update the sbt to the latest version 0.12.3, still no luck.
my build.sbt file:
organization := "com.typesafe.slick"
name := "slick-examples"
version := "1.0.1-RC1"
scalaVersion := "2.10.1"
scalacOptions += "-deprecation"
anyone please help me.
The Scala version sbt is using internally and the one used for your project are totally independent. Which sbt launcher are you using? Make sure you are using an sbt.version property that works for your sbt launcher.
Again, no need to configure the Scala version for your project at that level. Write a build.sbt file and set scalaVersion to, e.g. 2.10.1 (assuming you use sbt 0.12.x): scalaVersion := 2.10.1
One of my projects will provide a jar package supposed to be used for unit testing in several other projects. So far I managed to make sbt produce a objects-commons_2.10-0.1-SNAPSHOT-test.jar and have it published in my repository.
However, I can't find a way to tell sbt to use that artifact with the testing scope in other projects.
Adding the following dependencies in my build.scala will not get the test artifact loaded.
"com.company" %% "objects-commons" % "0.1-SNAPSHOT",
"com.company" %% "objects-commons" % "0.1-SNAPSHOT-test" % "test",
What I need is to use the default .jar file as compile and runtime dependency and the -test.jar as dependency in my test scope. But somehow sbt never tries to resolve the test jar.
How to use test artifacts
To enable publishing the test artifact when the main artifact is published you need to add to your build.sbt of the library:
publishArtifact in (Test, packageBin) := true
Publish your artifact. There should be at least two JARs: objects-commons_2.10.jar and objects-commons_2.10-test.jar.
To use the library at runtime and the test library at test scope add the following lines to build.sbt of the main application:
libraryDependencies ++= Seq("com.company" % "objects-commons_2.10" % "0.1-SNAPSHOT"
, "com.company" % "objects-commons_2.10" % "0.1-SNAPSHOT" % "test" classifier "tests" //for SBT 12: classifier test (not tests with s)
)
The first entry loads the the runtime libraries and the second entry forces that the "tests" artifact is only available in the test scope.
I created an example project:
git clone git#github.com:schleichardt/stackoverflow-answers.git --branch so15290881-how-do-i-resolve-my-own-test-artifacts-in-sbt
Or you can view the example directly in github.
Your problem is that sbt thinks that your two jars are the same artifact, but with different versions. It takes the "latest", which is 0.1-SNAPSHOT, and ignores the 0.1-SNAPSHOT-test. This is the same behaviour as you would see if, for instance you have 0.1-SNAPSHOT and 0.2-SNAPSHOT.
I don't know what is in these two jars, but if you want them both to be on the classpath, which is what you seem to want to do, then you'll need to change the name of the test artifact to objects-commons-test, as Kazuhiro suggested. It seems that this should be easy enough for you, since you're already putting it in the repo yourself.
It will work fine if you change the name like this.
"com.company" %% "objects-commons" % "0.1-SNAPSHOT",
"com.company" %% "objects-commons-test" % "0.1-SNAPSHOT" % "test",