Assume a hierarchical project layout as the following:
root
-subproject1
-subproject2
where root only aggregates all subprojects.
Calling eclipse in root, as expected, generates importable eclipse projects for all subprojects.
However, now consider that subproject 1 also aggregates subproject 2. Calling the eclipse task in either root or subproject 1 generates project files for all but subproject 1. In summary, having an "aggregation graph" such as
-> subproject1
/ |
root |
\ v
-> subproject2
never generates eclipse files for subproject 1.
Am I missing something about aggregation semantics or is this a bug in sbteclipse?
A concrete case where this problem occurs can be found in the build file here. Project "vfd-main" never has any eclipse projects generated unless removing its own aggregation settings on line 58.
Btw, I am using sbteclipse version 3.0.0
It turns out this is the expected behavior. Since subproject1 aggregates other projects, it is considered a parent and, by default, no project definitions are generated for parents. This can be changed by adding
EclipseKeys.skipParents in ThisBuild := false
to the build.
Related
I'm working on an SBT project that has to be built with the options like:
-Xmx2G -Xss256M -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled
This means that every new developer has to read the readme and assign the options to SBT_OPTS in bash profile or put them in the sbtopts file. Similarly, this has to be configured on Jenkins and this applies to all the projects (so if someone wants to use -XX:+UseG1GC with other projects it becomes an issue). Is it possible to specify the required options in the build file itself? This seems logical to me, as the options are project-specific and without them, you cannot build the project.
Create a .sbtopts file at the root of the build with contents:
-J-Xmx2G
-J-Xss256M
-J-XX:+UseConcMarkSweepGC
-J-XX:+CMSClassUnloadingEnabled
I'm trying to convert a single module project into two modules with a
root aggregate. Feels like a normal thing to do.
So, to simplify I have removed the second project that I added, but I
do something like:
cd myproject
mkdir core
mv * core
and then add a build.sbt in myproject like
lazy val root = project.in( file(".") ).aggregate(core)
lazy val core = project in file("core")
However, trying to build core I get:
[myproject]/core/build.sbt:22: error: not found: value lessSettings
seq(lessSettings:_*)
which is the settings for a plugin added in project/plugins.sbt of the
original project now in
[myproject]/core/project/plugins.sbt
How come this is not picked up? Can't I have plugins living only in
submodules? cd:ing into core submodule and running sbt it works just fine. Do I have
to move my plugins to root/project? Pretty please, it can't be so?
Your plugin.sbt file is ignored because you cannot have a project subfolder in a sub-project of a multi-project build.
In a multi-project build,
The .sbt files of the root project, and all .sbt files of all sub-projects, are all part of a single build definition. The settings defined in a sub-project are just automatically scoped to that project.
Since there is only one build definition, there is only one project to build that build definition, and that is in the project/ folder of the root project. All project/ folders of sub-projects will be ignored.
In your case, moving your plugin.sbt to the build root project folder should make your plugin appear again.
Furthermore, if you only work on the core project, instead of running sbt in core, you can run sbt in the root project and type project core to "move" (actually, scope everything you do) to the core sub-project.
I was a heavy Maven user and now I'm gradually using SBT for some of my projects.
I'd like to know how could I use SBT to create a standalone Java project? This project should be packaged as a JAR file and this JAR file would be used as a dependency in another SBT project.
In Maven, I could tell in my pom.xml what type of artifact it should produce when I build it. Is there something similar that I can do in SBT?
There is a difference between standalone and making a project useable as a dependency or another project. In the first case, you would use a plugin such as sbt-assembly. What it will do is create one jar file containing the project class files along with all of its dependencies. If you write an application, what you get is a double-clickable jar that you can execute from anywhere.
If you want to use your project A as a dependency for another project B, you have different options. You could just package the class files of A, using sbt package (answer of #Channing Walton). Then you could drop the resulting .jar file in the lib directory of project B. However, if A also requires libraries, you must make sure that they also end up in project B's libraries.
A better approach is to publish your project. You can do that purely on your local machine, using sbt publish-local. That will store the jar as produced by package in a special local directory which can be accessed from sbt in another project, along with a POM file that contains the dependencies of A. It will use a group-ID (organization) and artifact-ID (name) and a version of your project A. For example, in build.sbt:
name := "projecta"
version := "0.1.0-SNAPSHOT"
organization := "com.github.myname"
scalaVersion := "2.10.3"
publishMavenStyle := true
After publishing with sbt publish-local, you can add the following dependency to your project B:
libraryDependencies += "com.github.myname" %% "projecta" % "0.1.0-SNAPSHOT"
If you have a pure Java project, you can omit the Scala version suffix, i.e. in Project A:
crossPaths := false
autoScalaLibrary := false
And then in Project B:
libraryDependencies += "com.github.myname" % "projecta" % "0.1.0-SNAPSHOT"
(using only one % character between group and artifact ID).
More on publishing in the sbt documentation.
'sbt package' will produce a jar file.
If you want it to be executable you need to add the following to your .sbt config:
mainClass in Compile := Some("your.main.Class")
Sure, you can use 'sbt package' command, it creates a jar file but this jar will be without any dependencies. To run it necessary to specify 'classpath' arg to the libraries.
In your case you wish a standalone runnable file. And you need to add the dependencies.
To do this you can use 'assembly' plugin for SBT, see https://github.com/sbt/sbt-assembly/
Afterward you can just run 'sbt assembly' command, it provides a fat jar file with all dependencies that you can deploy and run anywhere and at any time.
For details see this article
publishLocal
builds the artifact and publish in the local Ivy repository making it available for your local project dependencies.
publishM2
same as above, but the artifact is published in local Maven repo instead of Ivy repo.
I think the easiest way to produce a stand-alone jar with your project in it,
is sadly not lying inside sbt.
I personally use my IDE: Intellij to make the jar (through the 'build artifact' feature).
Thanks to Intellij I can easily choose which library I want to include in the jar or not, (for instance the scala stl).
IMHO, this is by far the simplest method to get an executable jar for your project.
If you put the scala stl you can run your jar with the "java -jar" command, if you don't you have to run it somewhere with the correct version of scala installed with "scala".
Normally SBT looks for the build files at ./build.sbt and ./project/Build.scala. Is it possible to specify an alternate project root, so I can build a project not in the current working directory? I'm looking essentially for an equivalent to mvn -f /path/to/pom.xml but the docs have not provided me with any obvious answers.
(I should note that I want to do this at runtime rather than compile time. Essentially, I want to use sbt run-main to run arbitrary classes from my project, since I hate manual classpath wrangling. For various boring reasons I may need to do this from arbitrary location since the code may need the working directory to be something other than the project directory, so using cd might not do what I want. It's so trivial in Maven - I just assumed, perhaps unfairly, that there would be a simple equivalent in SBT)
I have something like this. I have project definition at X/build.sbt, X/MyOtherDefinitionWithSpecialThing/build.sbt, X/MySuperPublishConfig/build.sbt.
But my point of view to the problem is opposite. Instead of specify location of ./build.sbt and ./project/Build.scala I specify location of path to resources. The result is the same. It looks like:
sourceDirectory <<= (baseDirectory) (_ / ".." / "src")
target <<= (baseDirectory) (_ / ".." / "target")
This is allow to create single project with multiple definitions. This is worked with nested/hierarchical projects. But I use symbolic links (Linux OS) for hierarchical projects.
There is a file tree of one of my SBT plugins. Multiple build definitions and only one src/...
.
|-build.sbt
|-project
|---project
|-----target
|-------...
|---target
|-----...
|-project-0.11
|---build.sbt
|---project
|-----project
|-------target
|---------...
|-----target
|-------...
|-project-0.12
|---build.sbt
|---project
|-----project
|-------target
|---------...
|-----target
|-------...
|-...
|-src
|---main
|-----scala
|-------org
|---------...
|---sbt-test
|-----...
|-target
|---...
If this not solution of your problem please elaborate why you don't want use 'cd' command ;-)
-- For the updated use case:
I use shell wrapper and I have symlink to this one in every SBT project:
#!/bin/sh
#
here=$(cd $(dirname "$0"); pwd)
if [ ! -e "${here}/build.sbt" ]
then
echo build.sbt lost
exit
fi
cd ${here}
LOCAL_BUILD=true sbt-0.12 "$#"
I simply write /path/to/my/project/sbt 'show name' for example or /path/to/my/project/sbt run-main in your case.
As I discovered from this other answer, the sbt-start-script plugin is a better tool for this than sbt run-main. You can simply run sbt stage and you get an invocation script, with classpaths resolved, at target/start. According to the documentation, it needs to be run from the build root directory for inter-project dependencies to work, but for my simple use cases, this doesn't seem to be a problem.
I'm using sbt 0.10 to build a Scala project using just a build.sbt file instead of a full configuration.
Every time I start sbt it gives me the messages as follows:
[info] Set current project to default-ee699e (in build file:/Users/.../project/plugins/)
[info] Set current project to default-8febe7 (in build file:/Users/.../)
I did set the name and mainClass settings in the build.sbt file, so I don't know what I need to set to get the project names default-XXXX go away.
EDIT: the answer given below is correct in that this is cosmetic. If you switch to a full configuration of sbt, then it uses that project's name as opposed to default-XXXX however.
The message can be a bit misleading, it's not saying that you must "set the curent project", it's telling you what it's doing.
It sets the current project to the plugins folder, does it's stuff (compile, etc.), then sets the current project to your actual build folder and does it's thing once again.
You don't need to set anything else.