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
Related
PS D:\Users\erick\repos\leaderboard> sbt about
The Java Development Kit (JDK) installation you have is not up to date.
sbt requires at least version 6+, you have
version 0
Please go to http://www.oracle.com/technetwork/java/javase/downloads/ and download
a valid JDK and install before running sbt.
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
[info] Loading project definition from D:\Users\erick\repos\leaderboard\project
[info] Loading settings from build.sbt ...
[info] Set current project to leaderboard (in build file:/D:/Users/erick/repos/leaderboard/)
[info] This is sbt 1.1.4
[info] The current project is ProjectRef(uri("file:/D:/Users/erick/repos/leaderboard/"), "leaderboard") 0.0.0
[info] The current project is built against Scala 2.12.5
[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
Been searching for almost an hour for some way to suppress
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
in SBT, but it seems impossible. Is there some way to do this?
As usual, I seem to find the solutions shortly after posting the problem:
Go to SBT installation directory
edit conf/sbtconfig.txt
remove -XX:MaxPermSize=256m
Sadly, Google provides many sbt hits that are either wrong or out of date, so it takes a while to find valid solutions.
This Solution worked for me
Go to project directory
Open directory sbt-dist\conf
Open sbtconfig.txt file and comment below property by putting # prior the line
#-XX:MaxPermSize=256m
There are many solution which show downgrade to java version. You don't need to do just follow above steps . It will work.
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).
I'm interested in building an RPM package for sbt 0.12.3 that meets the Fedora packaging guidelines. In order to do this, I'll need to be able to build sbt itself against libraries that were built from source and installed via RPM packages.
Java packages in Fedora that use Ivy are able to resolve RPM-installed artifacts by disabling network resolvers and resolving all packages from /usr/share/java/[artifact].[ext] -- see here for an example.
I think I understand how to override default resolvers in sbt using a boot properties file, but this is where I run in to a problem: if I set the Ivy directory to /usr/share/java, sbt expects to be able to publish artifacts to this directory (not merely to look for existing artifacts there), which I don't want it to do (both in general and for this specific case of RPM building). If I specify file:///usr/share/java as a proxy location (following Mark's instructions below), sbt will fail (citing the absence of ivy.xml in that location).
I am able to find locally-installed dependencies by modifying project/p.sbt to point to explicit URLs (e.g. "org.jsoup" % "jsoup" % "1.7.1" from "file:///usr/share/java/jsoup.jar"), but this doesn't work for scala and the scala library (and is obviously not the right thing to do in general).
How can I build sbt against (and only against) locally-installed, RPM-managed system Scala and libraries?
I'm getting an error when running SBT, which I don't know where it originates from:
[info] Set current project to root (in build file:/home/dcs/.sbt/plugins/)
[warn] Potentially incompatible versions specified:
[warn] org.scala-tools.sbt: 0.10.1, 0.10.0
The JAR file for the sbt laucher is version's 0.10.1. The error happens even outside projects, such as when running screpl.
How do I fix it?
Do you have a build.sbt in /home/dcs/.sbt/build.properties that sets a particular sbt.version?
If not, you may have a global plugin installed that requires 0.10.0 as mentioned at https://groups.google.com/forum/#!topic/simple-build-tool/YoXd0Tp_cjo/discussion. The solution there was to wipe the global .sbt directory (your /home/dcs/.sbt).
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 :)