I created a multi-project build in sbt. Here's build.sbt in the main directory:
lazy val root = project in file(".") aggregate(data, reco, result)
lazy val data = project dependsOn(common)
lazy val reco = project
lazy val result = project dependsOn(common)
lazy val common = project
When I use package or one-jar command, the classes and resources in common project are not packaged into data or result jars. So when I run the generated jar by
java -jar data_2.10-1.0-onejar.jar
it leads to NoClassDefFoundError as a consequence.
So could anyone help me deal with such problem? Thanks in advance.
Your dependent projects are not exporting Jars (producing classes only). Put the following line in the build.sbt of all dependent projects (including your current project too, if necessary):
exportJars := true
That should fix it.
I might be misunderstanding your issue...please pardon me if I have.
From Classpath dependencies:
A project may depend on code in another project. This is done by
adding a dependsOn method call.
and later (in the same doc):
Now code in core can use classes from util. This also creates an
ordering between the projects when compiling them; util must be
updated and compiled before core can be compiled.
and then in Per-configuration classpath dependencies:
foo dependsOn(bar) means that the compile configuration in foo depends
on the compile configuration in bar.
We may also need to see what package is all about:
> help package
Produces the main artifact, such as a binary jar. This is typically an alias for the task that actually does the packaging.
or even inspect it to see what dependencies it has:
> inspect package
[info] Task: java.io.File
[info] Description:
[info] Produces the main artifact, such as a binary jar. This is typically an alias for the task that actually does the packaging.
[info] Provided by:
[info] {file:/C:/dev/sandbox/0.13.2/}root-0-13-2/compile:package
[info] Defined at:
[info] (sbt.Defaults) Defaults.scala:565
[info] Dependencies:
[info] compile:packageBin
[info] Delegates:
[info] compile:package
[info] *:package
[info] {.}/compile:package
[info] {.}/*:package
[info] */compile:package
[info] */*:package
[info] Related:
[info] jacoco:package
[info] test:package
With all that said, package doesn't package other project's artifacts - you need the sbt-assembly plugin instead (as you're crossing the boundaries of a single project and most if not all tasks in sbt are single-project only).
Related
I have downloaded sbt and to resolve the proxy maven repository errors, I have created repositories files with my-maven-proxy-releases: under ~/.sbt
When I do a sbt about, I get the below details:
"~\.sbt\preloaded\org.scala-sbt\sbt\"1.0.4"\jars\sbt.jar"
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
[warn] No sbt.version set in project/build.properties, base directory: C:\
[info] Set current project to root (in build file:/C:/)
[info] This is sbt 1.0.4
[info] The current project is {file:/C:/}root 0.1-SNAPSHOT
[info] The current project is built against Scala 2.12.4
[info] Available Plugins: sbt.plugins.IvyPlugin, sbt.plugins.JvmPlugin, sbt.plugins.CorePlugin, sbt.plugins.JUnitXmlReportPlugin, sbt.plugins.Giter8TemplatePlugin
[info] sbt, sbt plugins, and build definitions are using Scala 2.12.4
Now, I wanted to import a project in eclipse and I googled. This is the details I found.
1. ~/.sbt/<sbt-version>/plugins/plugins.sbt
addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "5.2.4")
sbteclipse
2. ~/.sbt/<sbt-version>/plugins/build.sbt
for scala versions and dependencies.
But I am confused on where to create the build.sbt and plugins.sbt as my folder structure is like this:
~/.sbt/1.0
~/.sbt/1.3
and I do not see ~/.sbt/1.0.4 which is displayed in sbt about.
Please guide if my understanding wrong.
First, you need to understand sbt project structure and the difference between project-local and global plugins.
As you would usually use eclipse plugin globally you should put it in
~/.sbt/<sbt-version>/plugins/plugins.sbt
(as you wrote correctly), where <sbt-version> is
0.13 for any sbt 0.13.*
1.0 for any sbt 1.*.* (this may seem unintuitive, but it's okay)
I guess, ~/.sbt/1.3 is just a typo and is meant to be ~/.sbt/0.13.
Also you normally don't put anything in ~/.sbt/<sbt-version>/plugins/build.sbt. If you need to have some global settings (including those for the global plugins), you should put them in
~/.sbt/<sbt-version>/global.sbt
Read about global settings here.
With non-global plugins and settings it's all the same minus the ~/.sbt/<sbt-version>/ part:
use <your-project>/plugins/plugins.sbt for plugins
and <your-project>/build.sbt for project settings
Once I run 'sbt compile' on a 2.3 play project, I can't use 'sbt compile' to compile any Play 2.2.x projects anymore. This is the error when I run sbt command.
[info] Loading project definition from /Users/macbookpro/playproject/project
[error] java.lang.NoClassDefFoundError: play/Play$
[error] Use 'last' for the full log.
Project loading failed: (r)etry, (q)uit, (l)ast, or (i)gnore?
I just had this same issue. In my case I was using Play 2.4, but it's probably the same cause. I had run activator ui in my project directory accidentally. It created a project/play-fork-run.sbt file which is for activator support, but was preventing sbt from working directly. Deleting that file cleared up the issue and I can now use sbt again.
Try updating play-fork-run.sbt
addSbtPlugin("com.typesafe.play" % "sbt-fork-run-plugin" % "2.3.8")
update to
addSbtPlugin("com.typesafe.play" % "sbt-fork-run-plugin" % "2.4.0")
Then project will be able to build.
That's interesting issue since it works for me (TM) on Mac OS X 10.9.3 with Java 7.
I downloaded the versions of Play - the latest 2.3.1 and the latest in 2.2.x stream - 2.2.3. With these two versions I've used activator (2.3.1) to create the web application and play for 2.2.3. Both worked well.
When I executed sbt compile in 2.3.1 and then 2.2.3, both commands worked fine, too. It took me some time to have all the dependencies downloaded, but at the end the results were as follows:
jacek:~/sandbox/play231-app
$ sbt compile
[info] Loading project definition from /Users/jacek/sandbox/play231-app/project
[info] Updating {file:/Users/jacek/sandbox/play231-app/project/}play231-app-build...
...
[info] Done updating.
[info] Compiling 5 Scala sources and 1 Java source to /Users/jacek/sandbox/play231-app/target/scala-2.11/classes...
[info] 'compiler-interface' not yet compiled for Scala 2.11.1. Compiling...
[info] Compilation completed in 14.895 s
[success] Total time: 200 s, completed Jun 25, 2014 1:00:18 PM
And for 2.2.3:
jacek:~/sandbox/play223-app
$ sbt compile
[info] Loading project definition from /Users/jacek/sandbox/play223-app/project
[info] Set current project to play223-app (in build file:/Users/jacek/sandbox/play223-app/)
[info] Updating {file:/Users/jacek/sandbox/play223-app/}play223-app...
...
[info] Done updating.
[info] Compiling 5 Scala sources and 1 Java source to /Users/jacek/sandbox/play223-app/target/scala-2.10/classes...
[info] 'compiler-interface' not yet compiled for Scala 2.10.3. Compiling...
[info] Compilation completed in 19.626 s
[success] Total time: 45 s, completed Jun 25, 2014 3:15:34 PM
I'm using sbt 0.13.5 installed using homebrew.
$ sbt --version
sbt launcher version 0.13.5
$ java -version
java version "1.7.0_60"
Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, mixed mode)
Play 2.3 app is supposed to be built using activator, to ensure proper sbt configuration. Best
I had the same issue. Make sure that you are using the java-8 version.
I was using java-7, changing to java-8 fixed my problem.
When I run sbt on one project directory, it issues Detected sbt version 0.12.1 when starting off.
Typing about and it repeats that version.
However, running sbt in a different project directory identifies its version as 0.11.3.
This reproduces even within the same terminal session. The version just varies per project directory. Couldn't find any explicit part in the build.sbt file that would cause this.
What could explain this?
In my case I'd like to use sbt 0.12.1 in both cases, how can I force that version being used also for the later project?
The project is a SBT multi-project and since each subproject is a separate project you can use project/build.properties to set different versions of SBT. The command is simply project-specific.
jacek:~/sandbox/stackoverflow
$ mkdir sbt-sample-project
jacek:~/sandbox/stackoverflow
$ cd sbt-sample-project
jacek:~/sandbox/stackoverflow/sbt-sample-project
$ tree
.
0 directories, 0 files
jacek:~/sandbox/stackoverflow/sbt-sample-project
$ sbt about
[info] Loading global plugins from /Users/jacek/.sbt/0.13/plugins
[info] Set current project to sbt-sample-project (in build file:/Users/jacek/sandbox/stackoverflow/sbt-sample-project/)
[info] This is sbt 0.13.0
[info] The current project is {file:/Users/jacek/sandbox/stackoverflow/sbt-sample-project/}sbt-sample-project 0.1-SNAPSHOT
[info] The current project is built against Scala 2.10.2
[info] Available Plugins: com.typesafe.sbt.SbtGit, com.typesafe.sbt.SbtProguard, growl.GrowlingTests, org.sbtidea.SbtIdeaPlugin, com.timushev.sbt.updates.UpdatesPlugin
[info] sbt, sbt plugins, and build definitions are using Scala 2.10.2
jacek:~/sandbox/stackoverflow/sbt-sample-project
$ mkdir project
jacek:~/sandbox/stackoverflow/sbt-sample-project
$ echo "sbt.version=0.13.1-RC5" > project/build.properties
jacek:~/sandbox/stackoverflow/sbt-sample-project
$ sbt about
[info] Loading global plugins from /Users/jacek/.sbt/0.13/plugins
[info] Updating {file:/Users/jacek/.sbt/0.13/plugins/}global-plugins...
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
[info] Loading project definition from /Users/jacek/sandbox/stackoverflow/sbt-sample-project/project
[info] Updating {file:/Users/jacek/sandbox/stackoverflow/sbt-sample-project/project/}sbt-sample-project-build...
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
[info] Set current project to sbt-sample-project (in build file:/Users/jacek/sandbox/stackoverflow/sbt-sample-project/)
[info] This is sbt 0.13.1-RC5
[info] The current project is {file:/Users/jacek/sandbox/stackoverflow/sbt-sample-project/}sbt-sample-project 0.1-SNAPSHOT
[info] The current project is built against Scala 2.10.3
[info] Available Plugins: com.typesafe.sbt.SbtGit, com.typesafe.sbt.SbtProguard, growl.GrowlingTests, org.sbtidea.SbtIdeaPlugin, com.timushev.sbt.updates.UpdatesPlugin
[info] sbt, sbt plugins, and build definitions are using Scala 2.10.3
How do I check which version of SBT I'm running?
I have the Bash file set up that uses sbt-launch.jar, and it works, but
sbt version
only shows the "project version" (0.1) and
sbt --version
does nothing.
sbt --version
It now works as of version 1.3.3+ (credit to #ElectronWill).
You may also want to use sbt about that (copying Mark Harrah's comment):
The about command was added recently to try to succinctly print the
most relevant information, including the sbt version.
Type "sbt about" and then Enter to get the SBT version:
Running the command, "sbt sbt-version" will simply output your current directory and the version number.
$ sbt sbt-version
[info] Set current project to spark (in build file:/home/morgan/code/spark/)
[info] 0.13.8
In SBT 0.13 and above, you can use the sbtVersion task (as pointed out by #steffen) or about command (as pointed out by #mark-harrah)
There's a difference how the sbtVersion task works in and outside a SBT project. When in a SBT project, sbtVersion displays the version of SBT used by the project and its subprojects.
$ sbt sbtVersion
[info] Loading global plugins from /Users/jacek/.sbt/0.13/plugins
[info] Updating {file:/Users/jacek/.sbt/0.13/plugins/}global-plugins...
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
[info] Loading project definition from /Users/jacek/oss/scalania/project
[info] Set current project to scalania (in build file:/Users/jacek/oss/scalania/)
[info] exercises/*:sbtVersion
[info] 0.13.1-RC5
[info] scalania/*:sbtVersion
[info] 0.13.1-RC5
It's set in project/build.properties:
jacek:~/oss/scalania
$ cat project/build.properties
sbt.version=0.13.1-RC5
The same task executed outside a SBT project shows the current version of the executable itself.
jacek:~
$ sbt sbtVersion
[info] Loading global plugins from /Users/jacek/.sbt/0.13/plugins
[info] Updating {file:/Users/jacek/.sbt/0.13/plugins/}global-plugins...
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
[info] Set current project to jacek (in build file:/Users/jacek/)
[info] 0.13.0
When you're outside, the about command seems to be a better fit as it shows the sbt version as well as Scala's and available plugins.
jacek:~
$ sbt about
[info] Loading global plugins from /Users/jacek/.sbt/0.13/plugins
[info] Set current project to jacek (in build file:/Users/jacek/)
[info] This is sbt 0.13.0
[info] The current project is {file:/Users/jacek/}jacek 0.1-SNAPSHOT
[info] The current project is built against Scala 2.10.2
[info] Available Plugins: com.typesafe.sbt.SbtGit, com.typesafe.sbt.SbtProguard, growl.GrowlingTests, org.sbtidea.SbtIdeaPlugin, com.timushev.sbt.updates.UpdatesPlugin
[info] sbt, sbt plugins, and build definitions are using Scala 2.10.2
You may want to run 'help about' to read its documentation:
jacek:~
$ sbt 'help about'
[info] Loading global plugins from /Users/jacek/.sbt/0.13/plugins
[info] Set current project to jacek (in build file:/Users/jacek/)
Displays basic information about sbt and the build.
For the sbtVersion setting, the inspect command can help.
$ sbt 'inspect sbtVersion'
[info] Loading global plugins from /Users/jacek/.sbt/0.13/plugins
[info] Set current project to jacek (in build file:/Users/jacek/)
[info] Setting: java.lang.String = 0.13.0
[info] Description:
[info] Provides the version of sbt. This setting should be not be modified.
[info] Provided by:
[info] */*:sbtVersion
[info] Defined at:
[info] (sbt.Defaults) Defaults.scala:67
[info] Delegates:
[info] *:sbtVersion
[info] {.}/*:sbtVersion
[info] */*:sbtVersion
[info] Related:
[info] */*:sbtVersion
The version setting that people seem to expect to inspect to know the SBT version is to set The version/revision of the current module.
$ sbt 'inspect version'
[info] Loading global plugins from /Users/jacek/.sbt/0.13/plugins
[info] Set current project to jacek (in build file:/Users/jacek/)
[info] Setting: java.lang.String = 0.1-SNAPSHOT
[info] Description:
[info] The version/revision of the current module.
[info] Provided by:
[info] */*:version
[info] Defined at:
[info] (sbt.Defaults) Defaults.scala:102
[info] Reverse dependencies:
[info] *:projectId
[info] *:isSnapshot
[info] Delegates:
[info] *:version
[info] {.}/*:version
[info] */*:version
[info] Related:
[info] */*:version
When used in a SBT project the tasks/settings may show different outputs.
You can use sbt about
Example:
C:\Users\smala>sbt about
[info] Set current project to smala (in build file:/C:/Users/smala/)
[info] This is sbt 0.13.6
[info] The current project is {file:/C:/Users/smala/}smala 0.1-SNAPSHOT
[info] The current project is built against Scala 2.10.4
[info] Available Plugins: sbt.plugins.IvyPlugin, sbt.plugins.JvmPlugin, sbt.plugins.CorePlugin, sbt.plugins.JUnitXmlReportPlugin
[info] sbt, sbt plugins, and build definitions are using Scala 2.10.4"
Recent versions of SBT finally support a standard --version flag!
$ sbt --version
sbt version in this project: 1.6.2
sbt script version: 1.6.2
(tested with 1.6+, but it seems that it has existed since at least 1.3.3)
From within the sbt shell
sbt:venkat> about
[info] This is sbt 1.3.3
...
What happens when you run sbt from the command line might have changed a bit over the 9 years since the question was originally posted.
Today, you will always be interacting with at least two "versions":
the launcher script (e.g. /usr/local/bin/sbt) version.[1] Check with sbt --script-version.
the default SBT version (=sbt-launcher JAR version), decided primarily by the project SBT version (in project/build.properties), secondarily by the launcher script itself. Check with sbt --script-version (or sbtVersion in the SBT shell)
Fortunately, in most day-to-day scenarios, the project SBT version is the only one that you need to be aware of.
1
It used to be just java -jar sbt-launcher.jar, then there was/is sbt-extras/sbt (aka "rebel cut"), then there was the "official" sbt script but in a separate github project called sbt-launcher-packaging (now archived). Today, the default script sits in the root folder of the sbt/sbt GH project and is generally the only version you need to worry about.
Run the SBT console and then type sbtVersion to check the SBT version, and scalaVersion for the Scala runtime version.
Doing sbt sbt-version led to some error as
[error] Not a valid command: sbt-version (similar: writeSbtVersion, session)
[error] Not a valid project ID: sbt-version
[error] Expected ':'
[error] Not a valid key: sbt-version (similar: sbtVersion, version, sbtBinaryVersion)
[error] sbt-version
[error] ^
As you can see the hint similar: sbtVersion, version, sbtBinaryVersion, all of them work but the correct one is generated by sbt sbtVersion
I have a fairly simple Flex SWC module that is compiled via the Maven Flexmojos plugin. This module also uses the flexmojos:generate goal during the generate-sources phase to create Actionscript3 equivalents of my Java services & domain classes. The regular sources are housed in src/main/flex and the generated sources are in src/main/flex-generated. The generated sources are NOT checked into Subversion. Like many other flexmojos users I use the build-helper:add-source goal to add this second source tree to my compile. This has been working well for months now and the Maven output typically looks like this:
[INFO] ------------------------------------------------------------------------
[INFO] Building myproj Core Client -- Flex Service
[INFO] task-segment: [deploy]
[INFO] ------------------------------------------------------------------------
[INFO] [flexmojos:generate {execution: create-actionscript-classes}]
[INFO] Flexmojos 3.7.1
[INFO] Apache License - Version 2.0 (NO WARRANTY) - See COPYRIGHT file
[INFO] flexmojos 3.7.1 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file
[INFO] Calling the generator for each Java class.
[INFO] Generating: /home/bsmith/develop/myproj/myproj-core/tags/myproj-core-1.0.2/flex-service/src/main/flex-generated/com/myprojvision/core/domain/security/Group.as
.......
[INFO] [build-helper:add-source {execution: add-source}]
[INFO] Source directory: /home/bsmith/develop/myproj/myproj-core/tags/myproj-core-1.0.2/flex-service/src/main/flex-generated added.
[INFO] Flex compiler configurations:
.....
-compiler.source-path /home/bsmith/develop/myproj/myproj-core/tags/myproj-core-1.0.2/flex-service/src/main/flex /home/bsmith/develop/myproj/myproj-core/tags/myproj-core-1.0.2/flex-service/src/main/flex
Notice how nicely the flex compiler source-path represents both source directories. This setup will successfully package, install, and deploy the SWC artifact. However, now we wish to use the Maven release plugin in order to automate the release process. The release:prepare goal runs fine. However, the release:perform goal fails because the flex compiler is not handed the generated source directory for some unknown reason:
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Building myproj Core Client -- Flex Service
[INFO] [INFO] task-segment: [deploy]
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] [flexmojos:generate {execution: create-actionscript-classes}]
[INFO] [INFO] Flexmojos 3.7.1
[INFO] [INFO] Apache License - Version 2.0 (NO WARRANTY) - See COPYRIGHT file
[INFO] [INFO] Calling the generator for each Java class.
[INFO] [INFO] Generating: /home/bsmith/develop/myproj/myproj-core/trunk/target/checkout/flex-service/src/main/flex-generated/com/myprojvision/core/domain/security/Group.as
...
[INFO] [INFO] [build-helper:add-source {execution: add-source}]
[INFO] [INFO] Source directory: /home/bsmith/develop/myproj/myproj-core/trunk/target/checkout/flex-service/src/main/flex-generated added.
...
[INFO] [INFO] Flex compiler configurations:
[INFO] -compiler.source-path /home/bsmith/develop/myproj/myproj-core/trunk/target/checkout/flex-service/src/main/flex
Notice that the files are generated in the right place, the build helper is correctly called, but the flex compiler.source-path is missing the generated source directory and thus a Flex class-not-found error is produced. What is so amazing to me about this problem is the the release:prepare does a [clean, verify] in a forked Maven lifecycle and it works, yet release:perform doesn't...so it doesn't seem that its the fork that is the problem.
Here is the configuration of the build-helper plugin:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${project.basedir}/src/main/flex-generated</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
Note that if I ditch the build-helper plug and use the flexmojo's sourcePaths configuration, then everything works fine.
<sourcePaths>
<path>${project.basedir}/src/main/flex</path>
<path>${project.basedir}/src/main/flex-generated</path>
</sourcePaths>
However sourcePaths is deprecated and the way forward for those with multiple flex source trees is build-helper.
Besides the flex-generated sources are not checked into SVN, may be you need to generate them under the target folder. I think this may confuse the release plugin. Try generating the sources under that folder and add it to the build with the build-helper plugin.
Having the same problem here as well. Doesn't seem to matter if the files are checked into version control or not, because I've tried it both with and without them checked in and the result was the same.
I'm going to try adding mine to the same source path to see if it fixes the problem, but it's certainly a compromise. The first time I tried doing that it seemed like GraniteDS didn't particularly care for it.
EDIT: I just took a look at the source code for the flexmojos plugin and sourcePaths is not deprecated. This was after a checkout from trunk
svn co http://svn.sonatype.org/flexmojos/trunk flexmojos
lo,
I had a problem similar to this in that I wanted to package an .xml file within my jar. To add it, I used the build-helper-maven-plugin and added it like you have above. Worked fine during build, but when it came to release:perform it would miss the .xml file out.
I found instead by using the <resources> section of the POM instead, I had a much better time. I also took the advice of this MaestroDev User Guide, treating the .xml file as a binary file and put some information in the POM to prevent it from being filtered.
MaestroDev User Guide (at the bottom called "Preventing Filtering of Binary Resources")
This seemed to work for me. Not sure if it's suitable for you because of how flex is built, but it doesn't look as if you've had an answer in a while and this might be it :)