I just started learning GCP and IntelliJ SBT for the first time.Please bear with me for any basic question.
My project structure:
Here is my SBT.Build
name := "MySBTproject"
version := "0.1"
scalaVersion := "2.11.12"
val moutlingyaml = "net.jcazevedo" %% "moultingyaml" % "0.4.2"
lazy val root = (project in file("."))
.settings(
name := "MySBTproject",
libraryDependencies += moutlingyaml
)
Then i ran SBT package from Terminal to create a jar as shown below
C:\Users\xyz\IdeaProjects\MySBTproject>SBT Package
After deploying this jar on to GCP bucket,i tried running the job using data proc
gcloud dataproc jobs submit spark \
--cluster my-cluster \
--region europe-north1 \
--jars gs://test-my-bucket-01/spark-jobs/mysbtproject_2.11-0.1.jar \
--class com.test.processing.jobs.mytestmain
I am getting below error once i run the job
Job failed with message [java.lang.ClassNotFoundException: com.test.processing.jobs.mytestmain]
Is it because of my custom project directory structure and build.sbt are not in sync?
Are any changes required, or do i need to create a jar from project sub-directory as shown below?
C:\Users\xyz\IdeaProjects\MySBTproject\ProcessDataDataProcessingJobs>SBT Package
src directory should be in directory pointed by project.in(directory). In your case project directory is ProcessData, while your src is in ProcessData/DataProcessingJobs. So I'm guessing that sbt doesn't see your code at all, doesn't compile it, and doesn't package it.
You can check it by opening JAR (after all it's just a ZIP file with classes in directories!) and by calling show sourceDirectories to see where sbt is looking for you code.
Since i do not have privilege to edit the question i am attaching the details as an answer.Once i get the proper answer i will delete my answer.
Below is the error i am getting when i am running from "run" on the IntelliJ window panel
Also i have verified the Jar file and found that no classes were there,And below is the contnets of jar and manifest file.
Manifest-Version: 1.0
Implementation-Title: MySBTproject
Implementation-Version: 0.1.0-SNAPSHOT
Specification-Vendor: default
Specification-Title: MySBTproject
Implementation-Vendor-Id: default
Specification-Version: 0.1.0-SNAPSHOT
Implementation-Vendor: default
and JAR file contents are in below image
request you to advise on what further needs to be done.
When i ran show directories command in sbt shell below are the outputs
MySBTproject> show sourceDirectories
[info] root / Compile / sourceDirectories
[info] List(C:\Users\XXXXX\IdeaProjects\MySBTproject\DataProcessingjobs\src\main\scala-2.11, C:\Users\XXXXXXXXX\IdeaProjects\MySBTproject\DataProcessingjobs\src\main\scala, C:\Users\XXXXXXXXX\IdeaProjects\MySBTproject\DataProcessingjobs\src\main\java, C:\Users\XXXXXXXXX\IdeaProjects\MySBTproject\DataProcessingjobs\target\scala-2.11\src_managed\main)
[info] Compile / sourceDirectories
[info] List(C:\Users\XXXXXX\IdeaProjects\MySBTproject\src\scala-2.12, C:\Users\XXXXXXXXX\IdeaProjects\MySBTproject\src\scala, C:\Users\XXXXXXXXX\IdeaProjects\MySBTproject\src\java, C:\Users\XXXXXXXXX\IdeaProjects\MySBTproject\target\scala-2.12\src_managed\main
[info] List(C:\Users\XXXXXX\IdeaProjects\MySBTproject\src\scala-2.12, C:\Users\XXXXXXXXX\IdeaProjects\MySBTproject\src\scala, C:\Users\XXXXXXXXX\IdeaProjects\MySBTproject\src\java, C:\Users\XXXXXXXXX\IdeaProjects\MySBTproject\target\scala-2.12\src_managed\main)
[IJ]sbt:MySBTproject>
I recently received the same error when executing a jar on Google Cloud DataProc. I'm not sure if this is the same issue you are having, but please give it a try if you are still having this issue and have not resolved it.
My setup is:
Scala 2.11.12
sbt 1.3.13
Spark SQL 2.3.2
For me, the issue was related to the removal of the system property io.grpc.internal.DnsNameResolverProvider.enable_grpclb in grpc v1.29.0. You can read more about it at the googleapis/java-logging issue on github from Oct 8, 2020. Look for the comment by user athakor.
The resolution was to add the dependencies:
libraryDependencies += "com.google.cloud" % "google-cloud-logging" % "1.102.0" exclude("io.grpc", "grpc-alts")
libraryDependencies += "io.grpc" % "grpc-alts" % "1.29.0"
Related
Got some trouble with a Scala Play app having a dependency on a Java library deployed to a local Maven repository using Gradle. I've setup a test project with a simple Gradle Java module containing one class, and a simple Scala Play project using this class. The Java class looks like:
public class TestClass {
public String testMethod(){
return "Some content we will change later.";
}
}
With a build.gradle setup to deploy JARs to local Maven repo:
apply plugin: 'java'
apply plugin: 'maven'
sourceCompatibility = 1.7
project.group = 'play-update-maven-snapshot'
version = '1.0-SNAPSHOT'
Running gradle install drops the JAR in the local repo:
$ ls ~/.m2/repository/play-update-maven-snapshot/gradle-java/1.0-SNAPSHOT/
gradle-java-1.0-SNAPSHOT.jar maven-metadata-local.xml
gradle-java-1.0-SNAPSHOT.pom
On the Scala/Play/SBT side, build.properties is updated to:
sbt.version=0.13.1
To pick up the changes noted in https://github.com/sbt/sbt/issues/321.
With build.sbt configured, according to the current SBT docs, for grabbing artifacts from local Maven repositories:
name := "play-scala"
version := "1.0-SNAPSHOT"
resolvers += "Local Maven Repository" at "file://"+Path.userHome.absolutePath+"/.m2/repository"
libraryDependencies ++= Seq(
jdbc,
anorm,
cache
)
libraryDependencies+= "play-update-maven-snapshot" % "gradle-java" % "1.0-SNAPSHOT"
play.Project.playScalaSettings
And Application.scala is updated to look like:
package controllers
import play.api.mvc._
object Application extends Controller {
def index = Action {
Ok(views.html.index(new TestClass().testMethod()))
}
}
And a hacked index.scala.html to simply display what is passed to it:
#(message: String)
#main("Welcome to Play") {
message
}
We have our simple test environment. Starting play does not show any dependency errors:
$ play run
[info] Loading project definition from /<redacted>/play-update-maven-snapshot/play-scala/project
[info] Set current project to play-scala (in build file:/<redacted>/play-update-maven-snapshot/play-scala/)
[info] Updating {file:/<redacted>/play-update-maven-snapshot/play-scala/}play-scala...
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
--- (Running the application from SBT, auto-reloading is enabled) ---
[info] play - Listening for HTTP on /0:0:0:0:0:0:0:0:9000
(Server started, use Ctrl+D to stop and go back to the console...)
Visiting localhost:9000 unfortunately give this:
[info] Compiling 5 Scala sources and 1 Java source to /<redacted>/play-update-maven-snapshot/play-scala/target/scala-2.10/classes...
[error] /<redacted>/play-update-maven-snapshot/play-scala/app/controllers/Application.scala:8: not found: type TestClass
[error] Ok(views.html.index(new TestClass().testMethod()))
It feels like this may have something to do with the old issue of SBT/Ivy caching local SNAPSHOTs, referenced above. However, deleting the Ivy cache with rm -Rf ~/.ivy2/cache/play-update-maven-snapshot does not seem to do anything.
Any pointers would be greatly appreciated. There's a GitHub project with the source here: https://github.com/timfulmer/play-update-maven-snapshot.
Edit 1:
Made sure JAR is actually in local repo:
$ ls -n ~/.m2/repository/play-update-maven-snapshot/gradle-java/1.0-SNAPSHOT/gradle-java-1.0-SNAPSHOT.jar
-rw-r--r-- 1 501 20 634 Feb 4 11:53 /Users/<redacted>/.m2/repository/play-update-maven-snapshot/gradle-java/1.0-SNAPSHOT/gradle-java-1.0-SNAPSHOT.jar
Updated build.sbt from
resolvers += "Local Maven Repository" at "file://"+Path.userHome.absolutePath+"/.m2/repository"
to
resolvers += Resolver.mavenLocal
Still no joy.
Edit 2:
Got really desperate :)
$ jar xvf ~/.m2/repository/play-update-maven-snapshot/gradle-java/1.0-SNAPSHOT/gradle-java-1.0-SNAPSHOT.jar
created: META-INF/
inflated: META-INF/MANIFEST.MF
inflated: TestClass.class
$ cat ./TestClass.class
????3
<init>()VCodeLineNumberTableLocalVariableTablethis
LTestClass;
testMethod()Ljava/lang/String;
SourceFileTestClass.java
"Some content we will change later.
TestClassjava/lang/Object!/*??
Looks like everything up to the local Maven repo is correct.
Thanks,
-- Tim
Dunno if this was an issue with earlier versions of the stack, but on a recent project with the exact same setup I did not run into this issue again. At the time it felt like something in the paths was getting cached once set incorrectly.
Being careful to follow the steps above in the order given with latest versions seems to make everything happy.
If you do run into this, please see the advice in the comments above. Aditya Pawade has some ideas on where the pesky files could be hiding.
Cheers,
-- Tim
I have installed Scala 2.10.3 and SBT 0.13.1. When I execute SBT following Hello, World from the SBT documentation I get the following error message:
"Error during sbt execution: No Scala version specified or detected"
I've tried to add a build.sbt file with the scalaVersion but the error keeps showing up.
Please advise.
I've just downgraded sbt to 0.12.3 and it works ... so what's wrong with 0.13.X ?
Its not an issue with the upgrade of 0.13.* version. Its the repository cache thats causing the issue. There are possibilities where you have broken / no ivys (when only the jar is downloaded through maven repo) for the sbt jars in your cache.
Once upgraded remove your ivy repo cache (or rename the folder) and remove the .sbt/boot folder (removing this will enable to start from the scratch)
Edit your ./sbt/repositories file and provide preference to the ivy repositories. If you are using proxy repositories which includes both ivy and maven style artifacts, the add it as below
[repositories]
local
maven-local
maven-central-ivy: http://<repository url>, [organization]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]
maven-central: http://<repository url>
This will enable especially (org.scala-sbt/sbt/*) to be download with the Ivys xml from where the version / revision and dependencies are picked up for the builds. If only the jar is downloaded from "maven-central", then the error occurs.
It is the problem of IDE you are using specially the scala plugin in it.
You can get ride of this just go to the folder where the build.sbt is created. Delete the "project" folder and open cmd, run "sbt" command on the folder, a new project folder will be created. Now you can open that in IDE.
It may be that you may find some problem very first in ide, if you build the project once , all the problems will go away.
I did exactly what #Gopi proposed but this is my repositories file content:
[repositories]
local
jcenter: https://jcenter.bintray.com/
maven-central
typesafe-ivy-releases: https://repo.typesafe.com/typesafe/ivy-releases/, [organization]/[module]/[revision]/[type]s/[artifact](-[classifier]).[ext], bootOnly
sbt-ivy-snapshots: https://repo.scala-sbt.org/scalasbt/ivy-snapshots/, [organization]/[module]/[revision]/[type]s/[artifact](-[classifier]).[ext], bootOnly
My SBT Version: 1.1.1
java version 1.8
Windows 10
Hope that helps,
BR. Paul
I've also installed both Scala and SBT on my machine through homebrew and can just run the given simple hello example, so i guess you did something wrong :-)
Please provide a bit more diagnostics, for example:
What is the output of both commands 'which sbt' and 'which scala'?
You should see the results as below:
$ which scala
/usr/local/bin/scala
$ which sbt
/usr/local/bin/sbt
$ ls -laF /usr/local/bin/sbt
lrwxr-xr-x 1 rjk admin 28 Feb 9 13:32 /usr/local/bin/sbt# -> ../Cellar/sbt/0.13.1/bin/sbt
$ ls -laF /usr/local/bin/scala
lrwxr-xr-x 1 rjk admin 32 Feb 9 13:38 /usr/local/bin/scala# -> ../Cellar/scala/2.10.3/bin/scala
And given the directory where you ran the example code from, is it completely empty besides the hw.scala example? Or did you also add the build.sbt or project/build.properties? If that's the case it would be wise to also list that here to spot any problems with them.
My question is: Why can't I publish from SBT to my server via SSH?
Context:
I am developing a scala library and I want to publish it to a remote repository with SBT v0.12.3 over SSH (using an SFTP resolver). The relevant portion of my project/Build.scala SBT settings file is configured as prescribed by https://github.com/harrah/xsbt/wiki/Resolvers:
publishTo <<= version { v =>
Some(Resolver.sftp(
"My Repository",
"example.com",
"/var/www/public_html/repositories/" + (
if (v.trim.endsWith("SNAPSHOT")) { "snapshots" } else { "releases" }
)
))
},
resolvers ++= Seq(
{
import java.io.File
val privateKeyFile: File = new File(sys.env("HOME") + "/.ssh/id_rsa")
Resolver.ssh("scala-sh", "example.com") as("my-username", privateKeyFile) withPermissions("0644")
},
...
),
When I run sbt publish, things go fine until the authorization, where it still attempts to prompt me for login/password. When I run it locally, it brings up the username/password prompt, and when I try to publish remotely while SSH'd in to a machine it fails with a java.awt.HeadlessException. The result appears to be that the desired private-key type of authentication is not being attempted.
Here is a log of the remote session publish attempt:
> sbt-version
[info] 0.12.3
> publish
[info] Packaging /home/me/my-lib/target/scala-2.10.1/my-lib_2.10.1-SNAPSHOT-sources.jar ...
[info] Done packaging.
[info] Wrote /home/me/my-lib/target/scala-2.10.1/my-lib_2.10.1-SNAPSHOT.pom
[info] :: delivering :: org.example#my-lib_2.10.1;SNAPSHOT :: SNAPSHOT :: release :: Sun Apr 21 12:48:59 PDT 2013
[info] delivering ivy file to /home/me/my-lib/target/scala-2.10.1/ivy-SNAPSHOT.xml
[info] Generating API documentation for main sources...
model contains 75 documentable templates
[info] API documentation generation successful.
[info] Packaging /home/me/my-lib/target/scala-2.10.1/my-lib_2.10.1-SNAPSHOT-javadoc.jar ...
[info] Done packaging.
[info] Packaging my-lib-SNAPSHOT.jar ...
[info] Done packaging.
[trace] Stack trace suppressed: run last *:publish for the full output.
[error] (*:publish) java.awt.HeadlessException:
[error] No X11 DISPLAY variable was set, but this program performed an operation which requires it.
[error] Total time: 35 s, completed Apr 21, 2013 12:49:33 PM
It fails because there is no X11 display. This is unexpected behavior because the SBT project configuration is set to use private key authentication (see resolvers above).
So far I can think of 2 possible causes for the problem, detailed below.
Possible cause #1: Misconfiguration of SBT
Is there a problem in my configuration above?
Possible cause #2: Hitting an Ivy bug from an old version
At time of writing, I am using the latest SBT, 0.12.3. Maybe the version of Ivy being used by SBT is old. The more I think about it, the less likely this seems, but I haven't been able to rule it out yet.
How can I find out what version of Ivy SBT is using?
and then..
IF it is old, is there a way to get SBT to use a newer version of ivy?
There is another relevant question, see ivy ssh publisher, which references[0] an Old Ivy bug which caused java.awt.HeadlessExceptions.
[0] ivy ssh publisher
"Which version of Ivy are you using? There is a Jira Bug for Version 2.0 : issues.apache.org/jira/browse/IVY-783 which should be fixed now."
"Seems like if I upgrade to ivy 2.3 rc-2. SSH publish works."
It may after all be an Ivy version related bug. I am using SBT 0.12.2, which AFAIK is using Ivy 2.0. I am looking at the Ivy cache, located in ~/.ivy2/cache/, where Ivy creates a bunch of XML log files for the dependencies it has resolved, and I can see Ivy module version 2.0 in every XML file generated.
I don't know of a way to update the Ivy version used by SBT, but judging by the default SBT documentation, a possible solution is to manually upgrade Ivy and make sure the default machine wide path points to the right Ivy version.
Then run sbt clean or sbt update to re-fetch dependencies and allow Ivy to regenerate XML config files, etc. for the new Ivy version. More on SBT dependency management HERE:
Ivy Home Directory
By default, sbt uses the standard Ivy home directory location
${user.home}/.ivy2/. This can be configured machine-wide, for use by
both the sbt launcher and by projects, by setting the system property
sbt.ivy.home in the sbt startup script (described in Setup).
For example:
java -Dsbt.ivy.home=/tmp/.ivy2/ ...
Update
By checking the SBT Scala source code for the latest version, the version issue is confirmed again. Even SBT 0.13 appears to be using Ivy version 2.0.0, not 2.3. Have a look at the SBT source code, specifically the last few lines of THIS file.
I know if I add withSources when I define one dependency, sbt can download that sources jar file automatically.
For example,
val specs = "org.scala-tools.testing" % "specs_2.8.1" % "1.6.6" % "test" withSources ()
But for the scala-library.jar and scala-compiler.jar, I don't need define them explicitly, how can I get sbt download their sources for me? So, I don't need config it manually after generate idea project using sbt-idea-plugin.
You have to change the boot properties. There is a nice description in the recent blog decodified from Mathias:
"How to make SBT download scala library sources" (started from #hseeberger key starting points)
Here is the relevant part (in case that link ever goes stale)
First, forget about trying to find some “hidden” setting in your SBT project definition enabling Scala library source download! It does not exist (at least not in SBT version 0.7.x).
Rather, there are these two things you need to do in order to whip SBT into submission:
Create an alternative configuration file for your SBT launcher.
Make the SBT launcher use it.
These are the steps in detail:
Find your sbt-launcher-0.7.x.jar file.
Since I’m on OS/X and use SBT via Homebrew mine lives at /usr/local/Cellar/sbt/0.7.5.RC0/libexec/sbt-launch-0.7.5.RC0.jar.
Extract the sbt.boot.properties from the sbt sub directory in the launcher jar
Fire up your favorite editor and change line 3 to classifiers: sources (uncomment the line)
Find the sbt script file you created during your SBT setup (e.g. ~/bin/sbt, or, when using Homebrew, /usr/local/Cellar/sbt/0.7.x/bin/sbt)
Add the path to your tweaked sbt.boot.properties file, prepended with an ’#’ character and in double quotes, as the second-to-last argument of the java call.
This is what my sbt script file looks like:
#!/bin/sh
java -Xmx768M -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=256m \
-jar /usr/local/Cellar/sbt/0.7.5.RC0/libexec/sbt-launch-0.7.5.RC0.jar \
"#/usr/local/Cellar/sbt/0.7.5.RC0/libexec/sbt.boot.properties" \
"$#"
Once you have completed these steps SBT should happily download the scala-...-sources.jar files for the Scala compiler and standard library for any new project you create.
To have SBT do this for an existing project, you have to manually delete the project/boot/scala-{version} directory before performing an ‘sbt update’ (SBT does not fetch additional source artifacts if the main jar is already present).
Once you have a custom sbt.boot.properties file, there are also other ways to supply it to the SBT launcher.
See SO question "how do I get sbt to use a local maven proxy repository (Nexus)?"
Based on Michael Slinn comments:
If you are using sbt 0.11.x and above, use this command:
sbt update-sbt-classifiers
Two pieces of information.
(1) SBT Documentation
http://www.scala-sbt.org/0.13.5/docs/Detailed-Topics/Library-Management.html
and I quote:
"To obtain particular classifiers for all dependencies transitively, run the updateClassifiers task. By default, this resolves all artifacts with the sources or javadoc classifier."
This means you should not need to do anything, but you can make it explicit and put in you build.sbt:
transitiveClassifiers := Seq("sources", "javadoc")
To actually get the sources downloaded by SBT then you do:
"updateClassifiers"
(2) If you are working with Eclipse scala IDE - most likely you are as development of plugins for Eclipse/Netebeans is a lot more active for eclipse - then you should configure your ecplise to find out the sources if you do the following.
EclipseKeys.withSource := true
Here is the documentation you should read,
https://github.com/typesafehub/sbteclipse/wiki/Using-sbteclipse
I've got an sbt (Scala) project that currently pulls artifacts from the web. We'd like to move towards a corporate-standardized Nexus repository that would cache artifacts. From the Nexus documentation, I understand how to do that for Maven projects. But sbt obviously uses a different approach. (I understand Ivy is involved somehow, but I've never used it and don't understand how it works.)
How do I tell sbt and/or the underlying Ivy to use the corporate Nexus repository system for all dependencies? I'd like the answer to use some sort of project-level configuration file, so that new clones of our source repository will automatically use the proxy. (I.e., mucking about with per-user config files in a dot-directory is not viable.)
Thanks!
Step 1: Follow the instructions at Detailed Topics: Proxy Repositories, which I have summarised and added to below:
(If you are using Artifactory, you can skip this step.) Create an entirely separate Maven proxy repository (or group) on your corporate Maven repository, to proxy ivy-style repositories such as these two important ones:
http://repo.typesafe.com/typesafe/ivy-releases/
http://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/
This is needed because some repository managers cannot handle Ivy-style and Maven-style repositories being mixed together.
Create a file repositories, listing both your main corporate repository and any extra one that you created in step 1, in the format shown below:
[repositories]
my-maven-proxy-releases: http://repo.example.com/maven-releases/
my-ivy-proxy-releases: http://repo.example.com/ivy-releases/, [organization]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]
Either save that file in the .sbt directory inside your home directory, or specify it on the sbt command line:
sbt -Dsbt.repository.config=<path-to-your-repo-file>
Good news for those using older versions of sbt: Even though, in the sbt 0.12.0 launcher jar at least, the boot properties files for older sbt versions don't contain the required line (the one that mentions repository.config), it will still work for those versions of sbt if you edit those files to add the required line, and repackage them into the sbt 0.12.0 launcher jar! This is because the feature is implemented in the launcher, not in sbt itself. And the sbt 0.12.0 launcher is claimed to be able to launch all versions of sbt, right back to 0.7!
Step 2: To make sure external repositories are not being used, remove the default repositories from your resolvers. This can be done in one of two ways:
Add the command line option -Dsbt.override.build.repos=true mentioned on the Detailed Topics page above. This will cause the repositories you specified in the file to override any repositories specified in any of your sbt files. This might only work in sbt 0.12 and above, though - I haven't tried it yet.
Use fullResolvers := Seq( resolver(s) for your corporate maven repositories ) in your build files, instead of resolvers ++= or resolvers := or whatever you used to use.
OK, with some help from Mark Harrah on the sbt mailing list, I have an answer that works.
My build class now looks like the following (plus some other repos):
import sbt._
//By extending DefaultWebProject, we get Jetty support
class OurApplication(info: ProjectInfo) extends DefaultWebProject(info) {
// This skips adding the default repositories and only uses the ones you added
// explicitly. --Mark Harrah
override def repositories = Set("OurNexus" at "http://our.nexus.server:9001/nexus/content/groups/public/")
override def ivyRepositories = Seq(Resolver.defaultLocal(None)) ++ repositories
/* Squeryl */
val squeryl = "org.squeryl" % "squeryl_2.8.0.RC3" % "0.9.4beta5"
/* DATE4J */
val date4j = "hirondelle.date4j" % "date4j" % "1.0" from "http://www.date4j.net/date4j.jar"
// etc
}
Now, if I delete the Squeryl tree from my machine's .ivy2/cache directory, sbt tries to grab it from the Nexus tree with the appropriate URL. Problem solved!
All you need is to define a property file sbt.boot.properties which will allow you to:
redefine the ivy cache location (I need that because it would be otherwise part of our roaming Windows profile, which is severely limited in disk space in our shop. See Issue 74)
define any other Maven repo you want
C:\HOMEWARE\apps\sbt-0.74\sbt.boot.properties
[scala]
version: 2.7.7
# classifiers: sources, javadoc
[app]
org: org.scala-tools.sbt
name: sbt
version: read(sbt.version)
class: sbt.xMain
components: xsbti
cross-versioned: true
classifiers: sources, javadoc
[repositories]
local
my-nexus: http://my.nexus/nexus/content/repositories/scala-tools/, [organization]/[module]/[revision]/[type]s/[artifact](-[classifier]).[ext]
maven-local
# sbt-db: http://databinder.net/repo/, [organization]/[module]/[revision]/[type]s/[artifact](-[classifier]).[ext]
# maven-central
# scala-tools-releases
# scala-tools-snapshots
[boot]
directory: project/boot
properties: project/build.properties
prompt-create: Project does not exist, create new project?
prompt-fill: true
quick-option: true
[log]
level: debug
[app-properties]
project.name: quick=set(test), new=prompt(Name)[p], fill=prompt(Name)
project.organization: new=prompt(Organization)[org.vonc]
project.version: quick=set(1.0), new=prompt(Version)[1.0], fill=prompt(Version)[1.0]
build.scala.versions: quick=set(2.8.0.RC2), new=prompt(Scala version)[2.8.0.RC2], fill=prompt(Scala version)[2.8.0.RC2]
sbt.version: quick=set(0.7.4), new=prompt(sbt version)[0.7.4], fill=prompt(sbt version)[0.7.4]
project.scratch: quick=set(true)
project.initialize: quick=set(true), new=set(true)
[ivy]
cache-directory: C:\HOMEWARE\projects\.ivy2\cache
Note: this sbt.boot.properties file is inspired from:
the one mentioned in the "Generalized Launcher" page of the sbt project.
the one found within sbt-0.74 itself!
I have commented any external Maven repository definition, and added a reference to my own Nexus Maven repo.
The launcher may be configured in one of the following ways in increasing order of precedence:
Replace the /sbt/sbt.boot.properties file in the jar.
Put a configuration file named sbt.boot.properties on the classpath. Put it in the classpath root without the /sbt prefix.
Specify the location of an alternate configuration on the command line. This can be done by:
either specifying the location as the system property sbt.boot.properties
or as the first argument to the launcher prefixed by '#'.
The system property has lower precedence.
Resolution of a relative path is:
first attempted against the current working directory,
then against the user's home directory,
and then against the directory containing the launcher jar.
An error is generated if none of these attempts succeed.
Define a sbt.bat wrapper (in order to be sure to specify your sbt.boot.properties) like:
C:\HOMEWARE>more C:\HOMEWARE\bin\sbt.BAT
#echo off
set t=%~dp0
set adp0=%t:C:\="%"
set SBT_DIR=%adp0%..\apps\sbt-0.74
dir C:\%SBT_DIR%\sbt-launch-0.7.4.jar
# if needed, add your proxy settings
set PROXY_OPTIONS=-Dhttp.proxyHost=my.proxy -Dhttp.proxyPort=80xx -Dhttp.proxyUser=auser -Dhttp.proxyPassword=yyyy
set JAVA_OPTIONS=-XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=256m -Xmx512M -cp C:\HOMEWARE\apps\sbt-0.74\sbt-launch-0.7.4
set SBT_BOOT_PROPERTIES=-Dsbt.boot.properties="sbt.boot.properties"
cmd /C C:\HOMEWARE\apps\jdk4eclipse\bin\java.exe %PROXY_OPTIONS% %JAVA_OPTIONS% %SBT_BOOT_PROPERTIES% -jar C:\HOMEWARE\apps\sbt-0.74\sbt-launch-0.7.4.jar %*
And your sbt will download artifacts only from:
your Nexus
your local Maven repo.
Just tested at home with an old Nexus opensource 1.6 I had running, java 1.6, sbt07.4
C:\Prog\Java\jdk1.6.0_18\jre\bin\java -Xmx512M -Dsbt.boot.properties=sbt.boot.properties - jar "c:\Prog\Scala\sbt\sbt-launch-0.7.4.jar"
That gives:
[success] Build completed successfully.
C:\Prog\Scala\tests\pp>sbt
Getting Scala 2.8.0 ...
downloading http://localhost:8081/nexus/content/repositories/scala/org/scala-lang/scala-compiler/2.8.0/scala-compiler-2.
8.0.jar ...
[SUCCESSFUL ] org.scala-lang#scala-compiler;2.8.0!scala-compiler.jar (311ms)
downloading http://localhost:8081/nexus/content/repositories/scala/org/scala-lang/scala-library/2.8.0/scala-library-2.8.
0.jar ...
[SUCCESSFUL ] org.scala-lang#scala-library;2.8.0!scala-library.jar (185ms)
:: retrieving :: org.scala-tools.sbt#boot-scala
confs: [default]
2 artifacts copied, 0 already retrieved (14484kB/167ms)
[info] Building project test 0.1 against Scala 2.8.0
[info] using sbt.DefaultProject with sbt 0.7.4 and Scala 2.7.7
If I try a funny value in the sbt.boot.properties file:
C:\Prog\Scala\tests\pp>sbt
Getting Scala 2.9.7 ...
:: problems summary ::
:::: WARNINGS
module not found: org.scala-lang#scala-compiler;2.9.7
==== nexus: tried
http://localhost:8081/nexus/content/repositories/scala/org/scala-lang/scala-compiler/2.9.7/scala-compiler-2.9.7.pom
-- artifact org.scala-lang#scala-compiler;2.9.7!scala-compiler.jar:
http://localhost:8081/nexus/content/repositories/scala/org/scala-lang/scala-compiler/2.9.7/scala-compiler-2.9.7.jar
So it does limit itself to the two repo I defined:
[repositories]
nexus: http://localhost:8081/nexus/content/repositories/scala
nexus2: http://localhost:8081/nexus/content/repositories/scala, [organization]/[module]/[revision]/[type]s/[artifact](-[classifier]).[ext]
(I commented everything else: local, maven-local, ...)
If I comment all repositories and put a funny value (2.7.9) for the scala version in the sbt.boot.properties, I do get (like the OP did)
C:\Prog\Scala\tests\pp>sbt
Error during sbt execution: No repositories defined.
If I put 2.7.7 (while still having all repo commented), yes, it won't generate an error:
C:\Prog\Scala\tests\pp>sbt
[info] Building project test 0.1 against Scala 2.8.0
[info] using sbt.DefaultProject with sbt 0.7.4 and Scala 2.7.7
But that's only because it already had downloaded scala2.8.0 during my previous tries.
If I remove that library from my project/boot directory, then it will throw an Exception:
[info] using sbt.DefaultProject with sbt 0.7.4 and Scala 2.7.7
> C:\Prog\Scala\tests\pp>sbt
Error during sbt execution: No repositories defined.
at xsbt.boot.Pre$.error(Pre.scala:18)
at xsbt.boot.Update.addResolvers(Update.scala:197)
...
at xsbt.boot.Boot$.main(Boot.scala:15)
at xsbt.boot.Boot.main(Boot.scala)
Error loading project: Error during sbt execution: No repositories defined.
edit the config file in sbt_home/conf "sbtconfig.txt"
add two line
-Dsbt.override.build.repos=true
-Dsbt.repository.config="C:/Program Files (x86)/sbt/conf/repo.properties"
the repo.properties content is
[repositories]
local
public: http://222.vvfox.com/public <-fix this ,write your local nexus group url
Well this has bugged me for a while so I found a guy that has written an SBT plugin for maven out on github called maven-sbt so all you have to do is include it in your plugins project and make your project mixin with maven.MavenDependencies and all your operations like update and publish-local work with your local maven. The nice thing about that is if you are like me, your org is all maven. So, all you libs are in you local maven repo but if for some reason you build with sbt first, then you start getting a bunch or jars in ivy too. What a waste of space, and time since you will still need to get them for your maven builds.
That said, I wish this were built into sbt so I would not need to add it to every project. Maybe as a processor at least. He mentioned in one thing I read that he would like to add it to 0.9 but I have not been able to find it.
I got this error because I had a blank file in ~/.sbt/repositories. Both adding repositories to the file and removing the file solved the problem.