scala & intellij : difficulties to create a runnnable jar - scala

I can't launch a scala jar; when I launch it I get the error "Exception in thread "main" java.lang.NoClassDefFoundError: scala/collection/immutable/List" which seems to mean the scala library is not loaded...
this is a screenshot showing a lot of informations on the artifact window.
here is the manifest:
Manifest-Version: 1.0
Class-Path: libs/scala-library-2.10.0.jar libs/commons-logging-1.1.1.j
ar libs/jcip-annotations-1.0.jar libs/jwnl-1.4_rc3.jar libs/laf-plugi
n-7.2.1.jar libs/laf-widget-7.2.1.jar libs/miglayout-core-4.2.jar lib
s/miglayout-swing-4.2.jar libs/scala-actors.jar libs/scala-library.ja
r libs/scala-swing.jar libs/slf4j-api-1.6.4.jar libs/slick_2.10-1.0.0
.jar libs/sqlite-jdbc-3.7.2.jar libs/substance-7.2.1.jar libs/trident
-7.2.1-swing.jar
Main-Class: Fenetre
and when I enter "java xf myJar.jar", there are extracted files in the directory:
- .class files
- in the libs folder, there are the libraries INCLUDING scala-library.jar & scala-library-2.10.0.jar(I specified only one of these two files in the manifest to avoid conflicts)
can you help me?

I'm new to Scala and don't know what the problem is however I've been compiling "fat jars" which include all the required libs.
I've been using https://github.com/sbt/sbt-assembly to do this successfully.

Despite what your manifest is telling you, when you run the application you either do not have the scala-library included in your class path or there's some confusion when you attempt to import List. Scala should automatically import the immutable collection classes in your project with the root Predef implementation.
Predef provides type aliases for types which are commonly used, such as the immutable collection types scala.collection.immutable.Map, scala.collection.immutable.Set, and the scala.collection.immutable.List constructors (scala.collection.immutable.:: and scala.collection.immutable.Nil). The types Pair (a scala.Tuple2) and Triple (a scala.Tuple3), with simple constructors, are also provided.
Predef in core Scaladocs
Try printing the classpath from within your app to confirm.
Although not pertinent to your question, I would recommend using SBT for dependency management now that IntelliJ IDEA 13 has full SBT integration support. Your collaborators not using IntelliJ will also be happier because SBT gives them more options for build technologies, editors, and other tooling when working on the project.

Related

Chisel: Compiling Chisel library on Windows

I have been using sbt on windows and a custom build.sbt script in conjunction with an import Chisel._ in the top-level file in order to generate Verilog from my Chisel source successfully.
I'm trying to get an IDE working on Windows to expedite Chisel development. I've gone with the Eclipse based SCALA IDE http://scala-ide.org/download/sdk.html/
I want to compile the Chisel library so that the import Chisel._ can be resolved locally, without having to go off and download the source from the repository each timeand recompile the source. When I download the Chisel-master repo from Git and include the src\main folder in my SCALA project in the SCALA IDE, I get lots of syntax errors in the Chisel SCALA files that prevent me from building the project.
Has anyone done anything like this before on Windows or have any knowledge of working with the SCALA IDE as it may just be a case of undefined symbols in the project configuration?
Not sure exactly what you did with build.sbt respect to recompile (I think it download it only the first time, then it caches it for the future). But I'm using ScalaIDE for Chisel on linux, using the default build.sbt files, maybe you can try to get it working out of the box first to help narrow down the issue.
Here are the steps I took in order to get ScalaIDE work with Chisel:
the latest Scala IDE uses 2.11.8, the current Chisel repository defaults to 2.11.7. So I had to change all the build.sbt reference to scalaVersion from 2.11.7 to 2.11.8
I used sbteclipse
https://github.com/typesafehub/sbteclipse
To create importable the workspace to setup the compilation dependencies.
Except for chiselFrontEnd. For some reason, this package is not added to the dependency. I have to Add chiselFrontEnd as a javabuildpath dependency manually (Properties/JavaBuildPath, under Projects) for my own projects.
To resolve undefined symbols, you can also add a JAR onto the project build path using Project Properties > Java Build Path > Libraries > Add External JARs...
If you are getting your JARs through Maven / SBT, they should be in:
C:\Users\<name>\.ivy2\local\edu.berkeley.cs\chisel3_2.11\jars
If you are using publish-local with chisel3, your JARs should be in
C:\Users\<name>\.ivy2\cache\edu.berkeley.cs\chisel3_2.11\jars
Note that chisel3 is compiled into one JAR, including coreMacros and chiselFrontend sub-projects
Of course, this is a more quick-and-dirty solution compared to something that can parse SBT files.

Scala: Read data from MANIFEST.MF

I'm building my Java/Scala project using maven-assembly-plugin,
I have a function in my project that prints my version number and I want to take it from MANIFEST.MF which is in the META-INF directory.
I found solutions for Java code but not for scala, the only thing I could find is scala.reflect.Manifest but I couldn't understand if it is relevant to my case.

How do I distribute a Scala macro as a project?

Suppose I have a Scala compile-time macro that I find useful and would like to share it (I do). How do I create a JAR file that when loaded into another project would execute the macro when compiling the new project?
Specifically, I've made a StaticAnnotation that rewrites the AST of the class that it wraps before compile time. This works in my Maven build (macro defined in the main directory, runs on test cases in the test directory) because I have
<compilerPlugins>
<compilerPlugin>
<groupId>org.scalamacros</groupId>
<artifactId>paradise_2.10.5</artifactId>
<version>2.1.0-M5</version>
</compilerPlugin>
</compilerPlugins>
in my scala-maven-plugin. (I'm starting with a Scala 2.10 project and if it works, will provide both 2.10 and 2.11.)
But if I put the resulting JAR on a Scala console classpath, in a Scala script, or into another Maven project (without special compiler plugins), it simply ignores the macro: the AST does not get overwritten and my compile-time println statements don't execute. If I use the #compileTimeOnly annotation on my macro (new in Scala 2.11), then it complains with the #compileTimeOnly error message.
Do I really need to tell my users to add compiler plugins in their pom.xml files, as well as alternate instructions for SBT and other build tools? Other packages containing macros (MacWire, Log4s) don't come with complicated build instructions: they just say, "point to this dependency in Maven Central." I couldn't find the magic in their build process that makes this work. What am I missing?
If you're relying on a macro-paradise-only feature then yes, you do need to tell your users to add compiler plugins. See http://docs.scala-lang.org/overviews/macros/annotations.html . The projects you mention are only using the scala compiler's built-in (non-paradise) macro features, not macro annotations.

import lift mapper caught an error missing jar file

hi im creating a lift scala application
this is my problem
when i import net.liftweb.mapper._ package the compiler gives me error...
i tried to add lift-mapper_2.9.1-2.4-M4.jar jar file to build path ,but the error exists..!
the compiler shows..
bad symbolic reference. A signature in package.class refers to term db in package net.liftweb which is not available. It may be completely missing from
the current classpath, or the version on the classpath might be incompatible with the version used when compiling package.class.
Try to add the mapper via SBT or maven configuration?
Anyway, Scala-2.9.1 and Lift 2.4-M4 are very-very out of date. Better use something like that for a good start: https://github.com/lift/lift_25_sbt/
It works out of the box, and you'll only have to add 1 line to add the mapper support for it. (After that, all dependencies would be downloaded and added to the project automatically, by SBT.)

I can't use sbt.Process inside /src?

I'm currently using sbt to build and run my scala programs. I'm trying to use sbt.Process to execute system commands. I must be missing something because when I try to import sbt.Process in one of my files in src/ I get this error.
not found: value sbt
[error] import sbt.Process._
So it looks like I can't access the sbt package inside my src/ files. What do I need to do to access it? Thanks.
SBT's environment (v 0.7.x) is only available in your build file or a Plugin.
The easiest way to use sbt.Process library (until 0.9.x which will have Process as an independent library) is to copy (BSD License) Process.scala and ProcessImpl.scala into your project
There are different classpaths for running sbt and compiling your source files.
One classpath is for compilation of files in directory project/build (that one contains sbt jars and usually scala library 2.7.7) and the other one is for building source files of your project (that one contains your dependencies from lib and lib_managed and usually scala library 2.8.*). If you'd like to use sbt.Process in your source files you can do two things:
add sbt jar to lib or lib_managed for it to be available on your project's classpath
use snapshot version of scala 2.9, it would have sbt Process built-in as sys.process package
Wait for Scala 2.9, and then just use it out of scala.sys.process.
sbt package has became an integral part of the Scala standard library since version 2.9
...this API has been included in the Scala standard library for version 2.9.
quoted from sbt wiki
Here's the link (scroll down)
well, in order to use it, all you have to do (assuming you are using sbt for build), is to add in build.sbt file the following line of code: sbtPlugin := true it will add the needed dependencies to your project.
of course, this solution is only to get your imports with sbt package to work. you should refactor your code to use the new package scala.sys.process like Daniel C. Sobral suggested.