I have a small project which uses Scala, Akka and Play combined. The way I set it up is the old-school way: download everything and link. I would like instead to mavenize the whole thing. Could you recommend me a clear, specific guide to do this? Thanks in advance.
Don't use Maven - use SBT - it's the build tool of choice.
Note maven is now squarely in the thoughtworks radar Hold section meaning nobody should be building new projects on it if you trust Fowler's advice: http://www.thoughtworks.com/radar
Play comes with sbt under the hood already so you shouldn't have to look to far from where you are now:
http://www.playframework.com/documentation/2.0/Build
Related
I'm working on a Scala project and wanted to play around with Hunspell. Since Hunspell seems to compile to native, it seems I need a JNA/JNI based API to deal with it. The link to the JNA version offered on the original Hunspell site is broken, though I managed to get the JNI version.
I've heard that JNA tends to be easier to use, which is what I'm looking for right now. I did find this repo: https://github.com/dren-dk/HunspellJNA, but it hasn't been updated in several years, so I'm not sure if it's a good idea to use it. I can't tell if it's a good version, or just someone's pet project that they abandoned halfway through.
My questions:
Is it a good idea to use this repo I found?
Does anyone know of a better way to use Hunspell with a Scala project?
I ended up using the BridJ version.
It seems to be a much simpler, bare bones version that's available on Maven Central, so I simply added the following line to my build.sbt.
"com.atlascopco" % "hunspell-bridj" % "1.0.4"
Github:
https://github.com/thomas-joiner/HunspellBridJ
Maven:
http://search.maven.org/#artifactdetails%7Ccom.atlascopco%7Chunspell-bridj%7C1.0.4%7Cjar
I need to integrate a scala library for reinforcement learning that works on scala 2.9.1 with a 2D game library. If it uses SBT that would be awesome.
I was looking at scage, however the current master branch is broken, it works on maven, and the examples for how to set up a starter project simply did not work.
I am not opposed to using a java library directly, but I really want to mimize the amount of work needed to get started.
Any suggestions?
How about ScalaFX?
At GitHub
JavaFX and Scala like milk and cookies
I think (see below) that I would like to structure a Clojure project as multiple modules, with ordered dependencies - just like Maven lets me do with multi-modules projects.
But I can't see how to do this with Leiningen - all I can see is the checkouts fix described in the FAQ which doesn't seem to be as powerful.
Will lein do this? Should I be using Gradle instead? Or is this kind of thing not needed?
Some more context: I am wondering how to architect a modular application that supports plugins (which I imagine means jars dumped on the classpath). And am wondering to what extent I can structure that as a core + plugins (I am thinking I should be able to do something with Clojure's dynamic code loading and not have to go with Java/OSGi). So I guess the driving motivation for a single project comes from wanting some way of packaging everything (the core + default plugins) as a single blob that is easy for the end user, but which can also be divided up (and which is built and tested in fragments, testing the logical independence of each module). More general advice about this is welcome
Update
A possible solution that wasn't mentioned below is using a Maven plugin - I assume that supports everything Maven does, but compiles Clojure, so will work with nested modules, etc.
First, it does not seem like Leiningen supports a module hierarchy like Maven does. The checkouts are the next closest thing it has. It should be sufficient though to develop a modular application in Clojure though.
For the project structure, I would have an API project, a "core" project, the plugins themselves, and a separate packaging project. The core and the plugins should only depend on the API. Which build tool you use to create the packaging project is up to you. Gradle would probably be more effective at handling the packaging, however having the "checkout" functionality Leiningen offers could make development of the system as a whole easier.
I would take a look at the code for Leiningen and Noir to figure out how to effectively handle this.
For dynamically loading the plugins, I would start with looking how Noir handles it in two of their files:
server.clj has namespace loading for all files under a particular namespace. Under the hood it uses tools.namespace, but you can easily see how it's used to require every namespace under a particular base. This is how Leiningen handles custom tasks as well - the base definition for the task should be in the leiningen.$task namespace.
core.clj has what I would use for plugin registration. In summary, use a map under an atom and add plugins to that map. I would advice wrapping the registration with a macro to keep your code cleaner.
What I listed above should be sufficient if you don't need to handle adding plugins at run time. If you don't have every plugin on the classpath during start-up, I would recommend utilizing pomegranite to add entries to the classpath. You can see an example in classpath.clj.
Groovy seems to fix a lot of the things I dislike about Java, and I was wondering if it would be possible to actually write an Eclipse plugin in Groovy instead of Java.
Does anyone know if this is possible, and if so how to go about it?
I've just found a blog entry which says it's not officially supported but is actually possible.
Not yet tested to see if it works, but it seems promising:
Writing Eclipse plugins with Groovy, by Jörn Dinkla
#Peter, I do not think that the blog post you linked to is complete or if it will really work. It is pointing to the old version of Groovy-Eclipse, which is no longer supported and is out of date.
Yes. It is possible to create your own plugins in Groovy.
First, install the Groovy-Eclipse plugin from here:
http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.7/
Then you can create a new plugin project and add the Groovy Nature.
Remove the Groovy Libraries classpath container
Instead, add the org.codehause.groovy as a required bundle
Create your Groovy code as normal
Now, the tricky part is exporting the plugin using PDE. See this blog post for how to do that: http://contraptionsforprogramming.blogspot.com/2010/08/groovy-pde-redux.html
One important thing to note is that you will need at least one Java file in your project for PDE to compile anything, It can be a dummy, empty file (this is a bug that has not yet been fixed).
Rejoice!
As an example, here is the codenarc Eclipse plugin that was written completely in Groovy:
http://sourceforge.net/projects/codenarceclipse/
You can also use JRuby, or Javascript ...
JAM Circle is a great example showing how to make great use of a scripting language in an Eclipse plugin, by allowing the end user to write his own actions and load them at runtime.
There's a proxy-like plugin that allows you to implement the plugin virtually in any language that supports JSR223 (javax.scripting)
I work on a fairly simple but large two-tier application that consists approximately 40 Eclipse RCP plugins. We have a new use case that is taking us to the web for a very small portion of this functionality. I'd like to prototype this using Lift. Clearly, I'm facing a few challenges.
Lift + OSGi. Can Lift get at OSGi bundles? Can it be packaged as an OSGi bundle itself and integrated into a web container?
Build System. We use the archaic Eclipse PDE build (read: Eclipse has no build system) with Cruise Control. Lift uses Maven.
Development Environment. This one I'm not sure anyone can help me with. I've tried to use the Scala plugin with Eclipse and it's still not ready. There are just too many impediments to make it useful. Saying that, I don't see this as a major issue because I can keep all the Lift code in one module, only referencing the Java code a very specific areas.
I'm wondering if anyone has tried anything similar to this and has any advice. Note that I won't be using any of the ORM stuff in Lift because all persistence is managed in the existing plugins behind an API. So, am I barking up the wrong tree? Is there something else I need to be aware of?
I could revert to simply using these instructions but I'd really like to take Lift for a spin because Java is... well... it's Java. :-(
There's thread in google groups about using lift as an OSGi bundle.
For the build system as far as I remember PDE sit's on top of ant, so you can use maven for building lift related stuff first and then call PDE's build.xml