I'm using latest version of sbt 0.13.7, and I'd like to set Class-Path header of my MANIFEST.MF file with all the project dependencies, and I don't really know how. I did read Configure packaging.
I do know how to set other headers like Main-Class:
mainClass in (Compile, packageBin) := Some("mypackage.MyClass")
I know it can be done with the sbt-assembly plugin, but I don't want to create one big jar, just a small jar, that includes all the dependencies.
I found I could set Class-Path with *.jar, as shown in this snippet:
packageOptions in (Compile, packageBin) +=
Package.ManifestAttributes(java.util.jar.Attributes.Name.CLASS_PATH -> "*.jar")
It appears a kind of workaround not a final solution. Any guidance very welcome.
Related
sbt seems to create an ivy.xml file, along with a pom file, during a publishLocal, even though ThisBuild / publishMavenStyle := true. It doesn't seem to be a problem with publish, because the ivy.xml file never makes it to the server. An sbt consumer of the locally published snapshot seems to use the ivy.xml file rather than the pom file. I've edited the pom file that gets produced using ThisBuild / pomPostProcess := ??? and would like to edit the ivy.xml similarly. We have access to ivySbt (and lots of other things), but I don't see how to edit the string or the XML nodes of the ivy file. Can anyone show how that might be done?
I am using the sbt revolver plugin to drive a vert.x scala project.
Currently I manually enter the following commands in sbt:
set mainClass in Revolver.reStart := Some("org.vertx.java.platform.impl.cli.Starter")
~re-start run scala:com.something.myClass
How could this be delegated to the build.sbt file, such that I can just run ~re-start in sbt, rather than those two commands every time?
It seems revolver has all the relevant configuration flexibility for that, but the sbt configuration language/conventions elude me and I failed to fiddle build.sbt to that effect.
You can add your settings to the build.sbt. It is rather simple, if you do set <whatever-here>, you can drop set and add it to the build.sbt directly.
For example, the build.sbt for your example would look like this.
build.sbt
Revolver.settings
mainClass in Revolver.reStart := Some("org.vertx.java.platform.impl.cli.Starter")
Revolver.reStartArgs := Seq("run", "scala:com.something.myClass")
The list of settings you can use is in the original link of yours, there are even some examples if you look down below.
I'm writing a library which depends on code (let's call it foo.jar) which is only available as a binary jar. As is standard, I'm putting this in the lib/ directory so SBT will treat is as an unmanaged dependency. This is fine so far.
However, since this is a library, I'd like to be able to publish it so that other projects which depend on it to also have access to the unmanaged code in foo.jar without having to manually locate it. I originally thought I could use a fat jar plugin such as SBT Assembly to create a jar with the dependencies, but that doesn't affect what is actually published using sbt publish-local – it only creates a fat jar when you run sbt assembly. Is there some standard simple way to handle this? It seems like a bad idea for every library which uses unmanaged dependencies to break when used by other projects downstream so I wonder if I'm missing something obvious.
I don't know if that's a good use of sbt-assembly, since other libraries could depend on a different version of foo.jar etc.
One way to work around it is to publish foo.jar in a Maven repository yourself. Some people in Scala and/or sbt community have been talking about bintray. It's still in beta, but looks promising if you want some jars published.
You might be able to get the result you want by manipulating the mappings in (Compile, packageBin) to include the files you want your packaged jar to have (publish uses the output from packageBin). This technique will allow you to include absolutely any file you want within the jar. The official sbt doc is here: http://www.scala-sbt.org/0.12.3/docs/Howto/package.html#contents
As an example, consider the common case of including a .properties file within your jar. Lets say you need to include "messages.properties" under the path "com/bigco/messages.properties" in your packaged jar. And lets say that this file is under src/main/scala/ ... You can add the following to your build.sbt:
mappings in (Compile, packageBin) <+= baseDirectory map { base =>
(base / "src" / "main" / "scala" / "com" / "bigco" / "messages.properties") -> "com/bigco/messages.properties"
}
To attempt to answer your original question, you could unzip foo.jar and add each one of the class files within to the packaged jar, according to their correct package paths. So something similar to
mappings in (Compile, packageBin) <+= baseDirectory map { base =>
(base / path / to / unzipped / file.class) -> "path.to.unzipped.file.class"
...
}
Or you might be able to get away with simply including foo.jar at the root of the packaged jar like so:
mappings in (Compile, packageBin) <+= baseDirectory map { base =>
(base / "lib" / "foo.jar") -> "foo.jar"
}
How can I copy managed libraries to a specific folder with Scala Build Tool?
For example:
All the jars from this managed library, would be put in 'project/lib'
libraryDependencies += "com.miglayout" % "miglayout-swt" % "4.2"
I found the solution. Pretty simple actually.
Add the following to build.sbt
This will copy the jars to project/lib_managed/jars//*.jar
retrieveManaged := true
I'm not sure about how to specify a specific folder, but this is good enough to get the jars under the project folder.
I'm new to SBT, using version 1.0 and a custom repository, and I've set the "retrieveManaged" flag mentioned here, but it seems that SBT only downloads the directly requested JARs, but not any of the JARs upon which those JARs depend. And yes, the repository is using the customary default format described in the answers here (though SBT/Ivy doesn't seem capable of retrieving snapshots, either, but that's a separate problem, I expect). The repository does not require any kind of authentication, FYI.
Here's a slightly generified version of my built.sbt file:
name := "MyProject"
organization := "com.myorg"
version := "0.1"
scalaVersion := "2.9.0"
scalacOptions += "-deprecation"
retrieveManaged := true
resolvers += Resolver.url("myorg", url("http://host.com//content/groups/public"))
libraryDependencies += "com.myorg" % "otherproject" % "1.0"
fork in run := true
The requested "otherproject" JAR file loads fine, but SBT/Ivy seems to have no interest in opening up its POM and downloading the other JARs it needs to operate. This seems like it should be a fairly basic function (Maven does it, for example) but I have no idea how to convince SBT/Ivy to do so. (And the documentation assures us that SBT is, in fact, supposed to do this: "By default, these declarations fetch all project dependencies, transitively".)
I believe I must be doing something wrong, but have no idea -- given how simple and vanilla this basic configuration is -- what it could be.
Standard, Maven-style repositories are declared like:
resolvers += "myorg" at "http://host.com/content/groups/public"
More details are at the Library Management page you linked to and on the Resolvers page.
Typically, one only uses Resolver.url when specifying non-standard layouts.