I'm starting to develop a Scala application with Swing using SBT. I figured out that I need two dependencies for a start, so that's scala-swing and javax.swing.SwingUtilities.
I've been searching the web, maven repositories and github, but stil couldn't find, where did the javax.swing package go.
So far I have found javax in Maven Repos, but javax.swing is not listed there for some reason.
I tried to add a javax dependency to my Build.scala:
val javax = "javax" % "javaee-api" % "7.0"
SBT downloaded several packages. Then I launched the terminal:
scala> import javax.swing.SwingUtilities
import javax.swing.SwingUtilities
scala> SwingUtilities.invokeLater()
<console>:9: error: not enough arguments for method invokeLater: (x$1: Runnable)Unit.
Unspecified value parameter x$1.
SwingUtilities.invokeLater()
^
That's scala console being launched from sbt project. So as you can see, import was successful and the console knows about invokeLater() method. But IntelliJ Idea still does not, it marks javax.swing as unresolvable, though it has downloaded the packages.
I'm completely stuck here.
javax.swing is part of any standard Java SE installation (see http://docs.oracle.com/javase/6/docs/api/ - there you have SwingUtilities), so there is no need to add a dependency. You only need the scala-swing dependency:
libraryDependencies += "org.scala-lang" % "scala-swing" % scalaVersion.value
If IntelliJ IDEA doesn't see javax.swing, you have probably not yet defined an "SDK". Go to File -> Project Structure -> Platform Settings -> SDKs. There you should have at least one entry such as "1.6" for Java 1.6 or "1.7" for Java 1.7. If not, press the "+" to add one and locate the appropriate Java home directory for the version you want to use (depends on your OS).
Related
I'm using the Play Framework 2.2.3 for my first time and I'm having a lot of trouble importing anorm._ and api.db.DB so I can set up my SQL databases.
My set-up is this:
MainController.scala
import play.api._
import play.api.mvc._
import play.api.db.DB
import anorm._
object MainController extends Controller {...}
application.conf
# db.default.driver=com.mysql.jdbc.Driver
# db.default.url="jdbc:mysql:/usr/local/path/to/database"
build.sbt
libraryDependencies += "mysql" % "mysql-connector-java" % "5.1.27"
My first question is whether or not I'm setting up MySQL database connection correctly. The other thing is that when I try to find the import with my IntelliJ, it finds it great. But when I compile in my browser, I get a compilation error: object db is not a member of package play.api. Any tips?
I downloaded both Play 2.2.2 and 2.2.3, and with both I had this problem so version problems are ruled out. I installed from the website, I unzipped the file into my Home folder, and used
play new app
cd app/
play
idea with-sources=yes
for my installation. I honestly just have no idea what's going on.
I have got the same issue and it's resolved by adding: "com.typesafe.play" % "play-iteratees_2.10" % "2.2.3", in my build.scala file.
simply add this to your dependency
<dependency>
<groupId>com.typesafe.play</groupId>
<artifactId>play-jdbc_2.11</artifactId>
<version>2.4.6</version>
</dependency>
Situation:
I want to execute JUnit test cases for my Play! 2.0 application on a Jenkins Server.
To build and test my app on the server I want to use SBT (with command sequence: clean compile test).
Problem:
Regardless of Jenkins, the command play test uses a different classpath than the command java -jar "sbt-launch.jar" test (both commands executed in the root directory of my play project, both commands use the same sbt version 0.12.2). My test cases can be compiled with play test but with java -jar "sbt-launch.jar" test the compiler complains that some JUnit classes (e.g., org.junit.rules.TestWatcher) are missing.
Analysis:
The command show test:full-classpath reveals that the classpathes indeed differ:
play test classpath contains: Attributed(<playhome>\repository\local\junit\junit-dep\4.10\jars\junit-dep.jar)
java -jar "sbt-launch.jar test classpath contains: Attributed(<userhome>\.ivy2\cache\junit\junit-dep\jars\junit-dep-4.8.2.jar)
Question:
Any ideas how to ensure that java -jar "sbt-launch.jar test uses the same classpath as play test?
Build.scala:
import sbt._
import Keys._
import play.Project._
object ApplicationBuild extends Build {
val appName = "my app"
val appVersion = "1.0-SNAPSHOT"
val appDependencies = Seq(
// Play framework dependencies
javaCore, javaJdbc, javaEbean,
// Add your project dependencies here
"com.typesafe" %% "play-plugins-mailer" % "2.1.0",
"com.feth" %% "play-authenticate" % "0.2.5-SNAPSHOT",
"org.mongodb" % "mongo-java-driver" % "2.10.1",
"com.embedly" % "embedly-api" % "0.1.5",
"org.mockito" % "mockito-all" % "1.9.5",
"org.mongojack" % "mongojack" % "2.0.0-RC5",
"commons-io" % "commons-io" % "2.3"
)
val main = play.Project(appName, appVersion, appDependencies).settings(
resolvers += Resolver.url("play-easymail (release)", url("http://joscha.github.com/play-easymail/repo/releases/"))(Resolver.ivyStylePatterns),
resolvers += Resolver.url("play-easymail (snapshot)", url("http://joscha.github.com/play-easymail/repo/snapshots/"))(Resolver.ivyStylePatterns),
resolvers += Resolver.url("play-authenticate (release)", url("http://joscha.github.com/play-authenticate/repo/releases/"))(Resolver.ivyStylePatterns),
resolvers += Resolver.url("play-authenticate (snapshot)", url("http://joscha.github.com/play-authenticate/repo/snapshots/"))(Resolver.ivyStylePatterns)
)
}
The play script rewires sbt to use a local JUnit file repository in addition to any remote you've used. This is why the download is so large. Ivy, by default, will not copy local files into its local cache, as it assumes they are stable.
SO, what you're seeing is the sbt script which downloaded the file vs. the Play script which has its own local repo that takes priority over the downloaded file.
Now the fun part is around versioning. Ivy has interesting version conflict resolution.
If you paste you look in your target/resolution-cache/reports directory, you may get some insight into the difference between the two commands and why the one junit is chosen over another. My guess is there's a dynamic version range which is looking in the local repository for the play script and not finding the newer version of junit-dep.
I am working with Play Framework 1.2.4, and using JSON-LIB to parse some JSON data from Java code.
Initially, I just put the 'json-lib-2.4-jdk15.jar' into the 'lib' folder, and the application worked fine. At some point, I got that this is not the right way to add libraries, and "play dependencies --sync" will even delete the JAR.
This is how my 'dependencies.yml' file looks now:
# Application dependencies
transitiveDependencies: false
require:
- play
- play -> crud
- play -> secure
- play -> cloudbees 0.2.2
- net.sf.flexjson -> flexjson 2.1
- net.sf.json-lib -> json-lib 2.4
Why I had a successful import of dependencies with 'flexjson', it fails with 'json-lib'.
Running "play dependencies -- verbose" gets to the following error:
:: problems summary ::
:::: WARNINGS
[NOT FOUND ] net.sf.json-lib#json-lib;2.4!json-lib.jar (347ms)
==== mavenCentral: tried
http://repo1.maven.org/maven2/net/sf/json-lib/json-lib/2.4/json-lib-2.4.jar
::::::::::::::::::::::::::::::::::::::::::::::
:: FAILED DOWNLOADS ::
:: ^ see resolution messages for details ^ ::
::::::::::::::::::::::::::::::::::::::::::::::
:: net.sf.json-lib#json-lib;2.4!json-lib.jar
::::::::::::::::::::::::::::::::::::::::::::::
Isn't it here?
http://mvnrepository.com/artifact/net.sf.json-lib/json-lib/2.4
In addition, the process brings additional JARs to the 'lib' folder: xerces, xalan etc. - even after I asked to ignore transitive dependencies.
2 questions:
1. What did I do wrong?
2. Is there a good way to "force" Play to recognize certain JAR as a "local" library (so it won't be downloaded from external repository), and yet allow working with other modules and libraries via 'dependencies' mechanism
I know that the scala swing libraries are present in scala 2.8:
[info] Building project chart 1.0 against Scala 2.8.1
[info] using sbt.DefaultProject with sbt 0.7.4 and Scala 2.7.7
So how come I'm getting this error:
[error] /src/main/scala/Chart.scala:2: value swing is not a member of package scala
[error] import scala.swing.Panel
Is it because SBT is using the wrong version of scala (i.e. 2.7.7)? If so, how do I configure it to use the correct version?
EDIT: Answer
Following Dylan Lacey's answer, I made the following file sbt/project/build/chart.scala:
import sbt._
class SamplesProject(info: ProjectInfo) extends DefaultProject(info)
{
val scalaSwing = "org.scala-lang" % "scala-swing" % "2.8.1"
}
Then I ran: sbt reload update from the shell.
Now things compile!
For sbt 0.11 (and presumably 0.10) then adding the following to build.sbt will do it:
libraryDependencies <+= scalaVersion { "org.scala-lang" % "scala-swing" % _ }
No. The version information reported on line 2 is just the version sbt was built with, it won't effect your build.
Because Swing is a package (Not part of the base classes) I suspect the problem is one of two things. Either:
Your build file doesn't specify that you want to use scala-swing and is getting confused. You can correct this by adding:
val scalaSwing = "org.scala-lang" % "scala-swing" % "packageVersion"
in your /project/build/projectName.scala (Thanks Janx!)
You've added the dependancy but have not yet downloaded the required package. To do this, you need sbt to reload your project definition and then get all required packages:
sbt reload update
If you need option 1, you'll likely need to also do option 2.
If neither of these work, you may have confused your local respository horribly. That can be fixed with a sbt clear-lib, but you will then re-download all your packages.
I know it's something silly, but for some reason Jython refuses to find javax.swing. I'm using Java 1.6.0_11. This is my start-up script:
#echo off
"%JAVA_HOME%\bin\java" -Xmx1024M -classpath ".;c:\Projects\Jython2.5.1\jython.jar" org.python.util.jython
My output looks like:
Jython 2.5.1 (Release_2_5_1:6813, Sep 26 2009, 13:47:54)
[Java HotSpot(TM) Client VM (Sun Microsystems Inc.)] on java1.6.0_10
Type "help", "copyright", "credits" or "license" for more information.
>>> import javax.swing
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named swing
>>> import javax
>>> dir(javax)
['__name__']
>>>
Most likely Jython is not scanning your packages. On startup, Jython tries to go through the jars and class files on its path and scan for Java packages. This is necessary because there is no way to look for Java packages by reflection. Package scanning can be deliberately turned off, or you could lack write privileges where it wants to write the cached information out see http://wiki.python.org/jython/PackageScanning for more. The best way to import Java classes is to do so explicitly class by class, like so:
from javax.swing import JFrame
This method should always work, even if package scanning is off or otherwise unable to work, and is the recommended approach (though it can be a bit tedious). If you do want to import packages (or if you want to do "from javax.swing import *" which also depends on package scanning - but is discouraged) you will need to figure out why your package scanning isn't working.
I had similar issues, and it turns out that since the standalone Jython dist does not support caching, it also does not support the "import *" approach. This is not clearly documented anywhere in the official Jython docs, but I concluded this based on a number of different bug reports:
https://groups.google.com/forum/?hl=en&fromgroups=#!topic/robotframework-users/6ipB0DYJkvU
http://bugs.jython.org/issue1778514
http://bugs.jython.org/issue1422
http://bugs.jython.org/issue1692579
Notable from that last link:
So as Oti noted, in standalone you must do full imports to succeed.
To fix your issue, use the non-standalone standard jython.jar generated by installing jython using the 'Standard' option.
If you wanted to package and distribute jython.jar with your application, in case a user does not have Jython installed, then you will also need to copy/pase the complete "Lib" folder from the jython installation directory into whichever location you end up placing jython.jar. This enables access to the python stdlib which is not included in the standard jar file.
UPDATE:
After playing around more, I think I have a fix to enable "import *" type imports even when using the standalone jar. All that needs to be done is to enable caching!
You can do this by either adding the following options to the jvm when running jython:
-Dpython.cachedir.skip=false -Dpython.cachedir=DESIRED CACHE PATH
(Note that the second argument is optional, and if left blank, a default value will be used)
If you are having an issue running the InteractiveConsole embedded in an app (which is what my problem was) you can add these properties before initializing the console:
Properties props = new Properties();
props.put("python.cachedir.skip", "false");
props.put("python.cachedir", "DESIRED CACHE PATH"); // again, this option is optional
InteractiveConsole.initialize(System.getProperties(), props, new String[0]);
I'm using Java 1.6.0_11
No, you're using
[Java HotSpot(TM) Client VM (Sun Microsystems Inc.)] on java1.6.0_10
What happens if you delete the cachedir from the Jython distribution directory, and try again?
Also, why are you explicitly setting the classpath that way? Why not simply
java -jar jython.jar
?