After a far shorter development cycle than for 2.8.0, Scala 2.8.1 reach us today.
More than 100 bugs were corrected, some of them really old (#36 !).
The great thing with that release is that for the first time ever, it is fully binary compatible with the previous one, Scala 2.8.0. With that and the creation of Scala Solution company, it seems to be really good insights toward Scala industrialization in the coming years.
I just published an article about how to set-up your Eclipse workspace in RAM to make I/O (almost) instantaneous. It was promised in the "Eclipse perfomance optimisation article", and now it's here: http://blog.normation.com/2010/07/27/set-up-eclipse-workspace-in-ram/
And like last time, any information about Eclipse optimization is much appreciated !
I just published a post on my company blog about how to implement a SyncRepl client using two different Java LDAP SDK, Apache DS and UnboundID:
http://blog.normation.com/2010/07/18/java-ldap-sdk-for-syncrepl-replication-showcase/
SyncRepl is a replication protocol for LDAP, normalized in RFC 4533.
The demonstration is done with a showcase web application that display in real time modification done in an LDAP server.
The application, named Syweno, was
developed in Scala, thanks to Liftweb and it's amazing Comet. It looks like:
The most awaited Scala version of all time (ok, it's easy for now...) is out, at last !
Congratulation to every body who contributed to make it happens, and long life to Scala post-2.8.0. After a brilliant childhood, perhaps it is time for the unruly teenager to quieten down a little and conquer the industrial world !
The official link:
http://www.scala-lang.org/node/7009
(orignal content from http://blog.normation.com/2010/07/01/scala-dreaded-underscore-psug )
On the evening of June 30th 2010, the Paris Scala User Group organized its second event.
This time, there were two presentations:
I just published an article about Eclipse perfomance optimisation, especially with the Scala IDE plugin, here : http://blog.normation.com/2010/05/24/optimizing-eclipse-performances/
This article mostly talk about generalities and gives some reference links about JVM tunning. It also contains some eclipse.ini examples, and point to reference topic on that subject.
A second, more involved article in which I will explain how to put your workspace into ram (and keep it synchronizes to disk, of course) will follow in a couple of days (ok, perhaps packed in weeks, depending of my work...).
Of course, any information about Eclipse optimization is much appreciated !
Following an older post, this is the pom I use as a starting point for Scala project which uses maven.
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.test</groupId>
<artifactId>test</artifactId>
<packaging>jar</packaging>
<version>0.1-SNAPSHOT</version>
<properties>
<!-- UTF-8 for everyone -->
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<!-- Other general properties -->
<slf4j-version>1.6.0</slf4j-version>
<logback-version>0.9.20</logback-version>
<scala-version>2.8.0.RC2</scala-version>
<scala-maven-plugin-version>2.13.1</scala-maven-plugin-version>
</properties>
<description>
Starting pom
</description>
<repositories>
<repository>
<id>scala-tools.org</id>
<name>Scala-tools Maven2 Repository</name>
<url>http://scala-tools.org/repo-releases</url>
</repository>
<repository>
<id>scala-snapshots.org</id>
<name>Scala-tools Maven2 Repository snapshots</name>
<url>http://scala-tools.org/repo-snapshots</url>
</repository>
<repository>
<id>no-commons-logging</id>
<name>No-commons-logging Maven Repository</name>
<layout>default</layout>
<url>http://no-commons-logging.zapto.org/mvn2</url>
<snapshots><enabled>false</enabled></snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>scala-tools.org</id>
<name>Scala-tools Maven2 Repository</name>
<url>http://scala-tools.org/repo-releases</url>
<snapshots><enabled>false</enabled></snapshots>
</pluginRepository>
<pluginRepository>
<id>scala-snapshots.org</id>
<name>Scala-tools Maven2 Repository snapshots</name>
<url>http://scala-tools.org/repo-snapshots</url>
</pluginRepository>
</pluginRepositories>
<build>
<sourceDirectory>src/main/scala</sourceDirectory>
<testSourceDirectory>src/test/scala</testSourceDirectory>
<plugins>
<plugin>
<groupId>org.scala-tools</groupId>
<artifactId>maven-scala-plugin</artifactId>
<version>${scala-maven-plugin-version}</version>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>testCompile</goal>
</goals>
</execution>
</executions>
<configuration>
<args>
<arg>-target:jvm-1.5</arg>
<arg>-make:transitivenocp</arg>
<arg>-dependencyfile</arg>
<arg>${project.build.directory}/.scala_dependencies</arg>
</args>
<jvmArgs>
<jvmArg>-client</jvmArg>
<jvmArg>-Xmx1G</jvmArg>
</jvmArgs>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.1</version>
<configuration>
<source>1.6</source>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>org.scala-lang</groupId>
<artifactId>scala-library</artifactId>
<version>${scala-version}</version>
</dependency>
<dependency>
<groupId>joda-time</groupId>
<artifactId>joda-time</artifactId>
<version>1.6</version>
</dependency>
<!-- test -->
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.7</version>
<scope>test</scope>
</dependency>
<!--
All the following is related to our will to NOT use Commong-logging
-->
<!-- use no-commons-logging -->
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>99.0-does-not-exist</version>
</dependency>
<!-- no-commons-logging-api, if you need it -->
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging-api</artifactId>
<version>99.0-does-not-exist</version>
</dependency>
<!-- the slf4j commons-logging replacement -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>${slf4j-version}</version>
</dependency>
<!-- the other slf4j jars -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j-version}</version>
</dependency>
<!-- using slf4j native backend -->
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<version>${logback-version}</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>${logback-version}</version>
</dependency>
</dependencies>
</project>
A great reception...
In a few hours, I'm going to take the TGV for Lausanne, to attend first Scala Days !
There seems to be a lots of really good conferences, and it will be the opportunity to finally met a lot of irc/mailing list names !
I just created a github project that shows what one has to do to configure and start OpenDS LDAP directory from a Java application, for example to run unit tests.
Most of the code is a direct transcription of information found on OpenDS wiki[1].
Along the commits, I tried to remove most of the unused configuration for the proposed goal, and I ended to replace the Berkeley DB backend by a memory one.
The source code is here: http://github.com/fanf/opends-simple-config
Feel free to remove even more unused configuration, or propose things to make OpenDS start time even faster.
Enjoy !
[1] https://www.opends.org/wiki/page/CreatingAnOpenDSInstanceForEmbeddedUse
https://www.opends.org/wiki/page/ControllingOpenDSFromAnotherApplication
Scala native DSL capabilities are astonishing. I just created some Scala object to mimic Unix file permission representation and "chmod" interaction, and I'm rather pleased of the result
Only user", "group" and "other" permission are managed - so no setuid, setgid or sticky bit.
scala> val p:Perm = wx scala> w.toString // "-wx" scala> w.octal // 3You can combine permission to obtain new permissions:
scala> w+r // rw- scala> rwx-w // r-w
scala> val perms = FilePerms(777)
scala> val perms = FilePerms(rw,rw,r)Like Perm, they have nice string and octal representation:
scala> val perms = FilePerms(777) scala> perms.toString //rwxrwxrwx scala> perms.octal // 777
scala> val perms = FilePerms(77) //rwxrwx--- scala> val perms = FilePerms(rw) //rw-------
scala> val perms = FilePerms(77) //rwxrwx--- scala> perms.g-wx // rwxr---- scala> perms.ugo+x // rwxr-x--x scala> perms.a-wx // r--r-----The binding of theses objects with Java IO with the goal to actually set file permissions is let as an exercise for the reader ;)
scala> object p { [enter]
| [here, past the content of the file]
.....
| }
defined module p
scala> import p._
import p._
scala> FilePerms(644)
res0: Option[p.FilePerms] = Some(rw-r--r--)
chmod( ug(_)+rw, filePerms)Not really nice.
Today, the first official "Scala 2.8 Beta" was released. It was awaited, and for really good reasons !
Just look at the announcement summary to see all the goodness available: http://www.scala-lang.org/node/4587
I would like to thanks all the people at EPFL and all other contributors around the world to provide us with such a good language and awesome libraries/tools for our daily work - both production ready thanks to Java existing ecosystem and Start-up friendly (ok, no argument here, I just like that language :)
Downloads are available here: http://www.scala-lang.org/downloads
Scala, Spring 3, Actor, REST, IoC configuration by code...
... and well, I should be able to put some other buzz words in that title, perhaps agile and Scrum ?
I wanted to test Spring 3 "configuration via code" new feature, and especially how well it works with Scala.
As a Tapestry 5 (former) user, I'm a great fan of IoC configuration done in Java (or Scala). From a developer point of view, it's so much more easy and robust (especially refactoring prone) to have access to a real, type safe language in place of an ersatz like XML... and most of the time, it's also much less verbose.
The application
I needed a pretext and decided to build a trivial web
application that allows to upload files to some URL, and post-process
them - a rather usual need in a web-application. That will allow to test Spring 3 new "REST"
features, a bit of Expression Language, and put in a little Scala Actor
to let the (long) processing be done asynchronously.
I also used maven, and Slf4j with NoCommonsLogging to be able to use Slf4j with Spring.
What exactly does the application:
- wait uploads on a REST endpoint URL;
- when an upload comes, save it into a temporary file;
- signal the file's availability to a "file processor". That processing may take a looooooong time to process (for example, it's a big XML report, with a lot of parsing, input validation, graphs generation, etc), and so, the processing should be done in a side process.
Results
Everything comes along really well, and the result is available on github.
To test it, you will need a JVM and Maven (if you haven't done it yet and are not limited by production constrains, just go download the last 1.6 JVM (1.6.0_18), the performances improvements with the last two releases are impressive)
% git clone git://github.com/fanf/scala-spring3-upload.git
% cd scala-spring3-upload
% mvn jetty:run
You should have a Jetty server up and running on localhost.% curl -F FileToUploadName=@/path/to/the/file/to/upload http://localhost:8080/upload/
For me, year 2010 will be a big switch in my life... hopefully for the best !
So, I wish you all the best things for this last year of the first third millennium's decade !
Happy new year !
© Blogger template 'Minimalist G' by Ourblogtemplates.com 2008
Back to TOP