{"id":528,"date":"2011-11-08T14:35:37","date_gmt":"2011-11-08T13:35:37","guid":{"rendered":"http:\/\/www.xenonique.co.uk\/blog\/?p=528"},"modified":"2011-11-09T13:27:44","modified_gmt":"2011-11-09T12:27:44","slug":"scalafx-scala-build-tool-and-javafx-2-0-libraries","status":"publish","type":"post","link":"https:\/\/www.xenonique.co.uk\/blog\/2011\/11\/08\/scalafx-scala-build-tool-and-javafx-2-0-libraries\/","title":{"rendered":"ScalaFX, Scala Build Tool and JavaFX 2.0 Libraries"},"content":{"rendered":"

Hard Reference<\/h2>\n

In my last blog entry, ScalaFX A Walkthrough<\/strong><\/a>, I talked about setting up ScalaFX 2.0 in IntelliJ 10.5 with the Scala Build Tool (SBT) in the screencast. I left out some salient points.<\/p>\n

The JavaFX 2.0 SDK has one important hardcoded reference in it, which makes it hard to use in a Maven or Ivy repository. The reference is in a class called NativeLibLoader<\/code> and it attempts to initialise the native library with a fixed path. The actually call is something like this:<\/p>\n

\r\n      AccessController.doPrivileged(new PrivilegedAction() {\r\n        public Object run() {\r\n          NativeLibLoader.loadLibrary("mat");\r\n          return null;\r\n        }\r\n      });\r\n<\/pre>\n
 <\/p>\n
The NativeLibLoader<\/code> class JavaFX 2.0 expects to find native libraries in the \u201c\/..\/bin\u201d<\/code> of the class path that references jfxrt.jar<\/code>.<\/p>\n
In order, to get a around the problem you need to manually copy all of JavaFX 2.0 native libraries (*.DLL files) to SBT folders as well.<\/p>\n
First, create the directory:<\/p>\n
\r\ncd scalafx\r\nmkdir lib_managed\\jars\\com.oracle\\bin\r\n<\/pre>\n
 
\nNote: SBT uses Apache Ivy underneath the hood, hence the peculiar non-Maven group name “com.oracle” as the pathname.<\/p>\n
Then, copy the native libraries over:<\/p>\n
\r\ncopy \u201c%JAVAFX_HOME%\u201d\\rt\\bin\\*.dll\u00a0\u00a0 lib_managed\\jars\\com.oracle\\bin\r\n<\/pre>\n
 <\/p>\n
After this fix for the missing native library, you can build the ScalaFX library successfully using SBT:<\/p>\n
 sbt\r\n> compile\r\n> test\r\n> run\r\n> exit\r\n<\/pre>\n
 <\/p>\n
Finally, in order to generate a JAR file, you then execute sbt thus:<\/p>\n
\r\nsbt package\r\nsbt clean compile test package\r\n<\/pre>\n
 <\/p>\n
Look in the folder \"target\"<\/code> for \"scalafx-1.0.jar<\/code>. <\/p>\n
Here are some of the SBT fragments that I added to my version the build.sbt<\/code> file that will help you get configured:<\/p>\n
\r\n\/\/ Upgraded the latest Scala version from 2.9.0.1 to 2.9.1\r\nscalaVersion := "2.9.1"\r\n\r\n\/\/ Harded code my local repository, because the following breaks Windows file resolution\r\n\/\/ resolvers += "Local Maven Repository" at "file:\/\/"+Path.userHome.absolutePath+"\/.m2\/repository"\r\nresolvers += "Local Maven Repository" at "file:\/\/\/Users\/Peter\/.m2\/repository"\r\n\r\n\/\/ UPGRADE to JAVAFX 2.0 Final Candidate Status (FCS)\r\nlibraryDependencies ++= Seq(\r\n    "com.oracle" % "javafx-runtime" % "2.0"\r\n)\r\n\r\n\/\/ Everyone should using Java 1.6 by now shouldn't they?\r\njavacOptions ++= Seq("-source", "1.6", "-target", "1.6")\r\n\r\n\/\/ Reduce the JVM heap space for my laptop!\r\njavaOptions += "-Xmx384M"\r\n\r\n\/\/ Change the JAVA home to something on your system, if required\r\n\/\/ javaHome := Some(file("\/Library\/Java\/JavaVirtualMachines\/1.6.0_24-b07-330.jdk\/Contents\/Home"))\r\njavaHome := Some(file("\/Program Files\/Java\/jdk1.6.0_29" ))\r\n\r\n<\/pre>\n
 
\nIn order to install the JAR into a local Maven Repository, you need to add the following stanza to the build.sbt<\/code> file. Again, this is not portable as it directly reflects my machine and my user space.<\/p>\n
\r\n\/\/ Set publish Maven for local repository\r\npublishMavenStyle := true\r\n\/\/ Set up the Maven repository\r\npublishTo := Some(Resolver.file("file",  new File( "\/Users\/Peter\/.m2\/repository" )) )\r\n<\/pre>\n
 
\nNow, you can run the SBT command “publish” like so:<\/p>\n
\r\n> sbt publish \r\n[info]  published scalafx to C:\/Users\/Peter\/.m2\/repository\/org\/scalafx\/scalafx\/1.0\/scalafx-1.0.pom\r\n[info]  published scalafx to C:\/Users\/Peter\/.m2\/repository\/org\/scalafx\/scalafx\/1.0\/scalafx-1.0.jar\r\n[info]  published scalafx to C:\/Users\/Peter\/.m2\/repository\/org\/scalafx\/scalafx\/1.0\/scalafx-1.0-sources.jar\r\n<\/pre>\n
 
\nAs you can see this is the equivalent of invoking mvn install:install-file<\/code> almost. <\/p>\n
If you want to install to a local Apache Ivy then use the SBT command “publish-local” instead.<\/p>\n
\r\n> sbt publish-local\r\n[info]  published scalafx to C:\\Users\\peter\\.ivy2\/local\/org.scalafx\/scalafx\/1.0\/poms\/scalafx.pom\r\n[info]  published scalafx to C:\\Users\\peter\\.ivy2\/local\/org.scalafx\/scalafx\/1.0\/jars\/scalafx.jar\r\n[info]  published scalafx to C:\\Users\\peter\\.ivy2\/local\/org.scalafx\/scalafx\/1.0\/srcs\/scalafx-sources.jar\r\n[info]  published ivy to C:\\Users\\peter\\.ivy2\/local\/org.scalafx\/scalafx\/1.0\/ivys\/ivy.xml\r\n<\/pre>\n
 <\/p>\n
Please let me know, if you have any more problems. Thanks.
\n <\/p>\n
IntelliJ and SBT<\/h2>\n
<\/p>\n
There was a definite bug in SBT Plug-in for IntelliJ IDEA<\/strong><\/a> that prevents the command line input working more than once. I explained this in the video screencast. However, It has been fixed recently, so make sure you update this plug-in to get the fix.<\/p>\n
 <\/p>\n
Proposal<\/h2>\n
This copying of manuals DLL is a real pain for Maven \/ Ivy \/ SBT developers, because we have do this every single project. I believe Oracle could standardise on the actualise “platform” name (e.g. “Win”, “Mac”, “Solaris”, “Linux”) for the actual loading or come up with a way of making the mechanism indirect. Let me make myself abundantly clear:<\/p>\n
\r\n\/\/ This SBT stanza will not work!!! It is just for illustration\r\nlibraryDependencies ++= Seq(\r\n  "com.oracle" % "javafx" % "2.0" % "provided" ,\r\n  ( \r\n  "com.oracle" % "javafx-windows" % "2.0" % "provided" |\r\n  "com.oracle" % "javafx-macosx" % "2.0" % "provided" |\r\n  "com.oracle" % "javafx-solaris" % "2.0" % "provided" |\r\n  "com.oracle" % "javafx-linux" % "2.0" % "provided" )\r\n}\r\n<\/pre>\n
Therefore Linux native libraries (*.so file) would in a known repository folder and of course you create a POM or IVY file and these entries:<\/p>\n
\r\n~\/.m2\/repository\/com\/oracle\/javafx-linux\r\n<\/pre>\n
We know that genuine differences exists in OS and CPU architecture and even chip hardware and therefore we should be sensitive to native changes e.g. Windows 32 versus 64 bit and AMD\/Intel then may be schema could like this:<\/p>\n
\r\nlibraryDependencies ++= Seq(\r\n  "com.oracle" % "javafx" % "2.0" % "provided" ,\r\n  "com.oracle" % "javafx-${PLATFORM}[-${VERSION}][-${ARCHITECTURE}][-${CHIPSET}]" % "2.0" % "provided" \r\n}\r\n\/\/ PLATFORM is "windows" and VERSION is "" or "7" or "8"\r\n\/\/ and ARCHITECTURE is "" or "32bit" or "64bit"\r\n\/\/ and also CHIPSET is "" or "Intel" or "AMD"\r\n\r\n<\/pre>\n
I would be very interested in your thoughts on this scheme above. Thank you in advance.<\/p>\n","protected":false},"excerpt":{"rendered":"
Hard Reference In my last blog entry, ScalaFX A Walkthrough, I talked about setting up ScalaFX 2.0 in IntelliJ 10.5 with the Scala Build Tool (SBT) in the screencast. I left out some salient points. The JavaFX 2.0 SDK has one important hardcoded reference in it, which makes it hard to use in a Maven […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[75,4,5,40,6],"tags":[],"_links":{"self":[{"href":"https:\/\/www.xenonique.co.uk\/blog\/wp-json\/wp\/v2\/posts\/528"}],"collection":[{"href":"https:\/\/www.xenonique.co.uk\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.xenonique.co.uk\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.xenonique.co.uk\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.xenonique.co.uk\/blog\/wp-json\/wp\/v2\/comments?post=528"}],"version-history":[{"count":17,"href":"https:\/\/www.xenonique.co.uk\/blog\/wp-json\/wp\/v2\/posts\/528\/revisions"}],"predecessor-version":[{"id":535,"href":"https:\/\/www.xenonique.co.uk\/blog\/wp-json\/wp\/v2\/posts\/528\/revisions\/535"}],"wp:attachment":[{"href":"https:\/\/www.xenonique.co.uk\/blog\/wp-json\/wp\/v2\/media?parent=528"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.xenonique.co.uk\/blog\/wp-json\/wp\/v2\/categories?post=528"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.xenonique.co.uk\/blog\/wp-json\/wp\/v2\/tags?post=528"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}