22 7 / 2014

scalikejdbc 2.0.6

ScalikeJDBC 2.0.6 is out.


ScalikeJDBC Logo



  • Add in, notIn, exists, notExists with subQuery to SQLSyntax

Enjoy writing mostly type-safe SQL and get things done!

ScalikeJDBC is a tidy SQL-based DB access library for Scala.

21 7 / 2014

retry 0.2.0



Retries are now defined in terms of a common and easier to work with interface, a retry.Policy, which is in essence the type

() => Future[T] => Future[T]

with a few implicit parameters: one for an instance of a retry.Success[T] and one for an scala.concurrent.ExecutionContext.

This makes the packaging of retry logic more portable as easier to swap implementations in an out.

trait Policy {
  def apply[T](promise: () => Future[T])
   (implicit success: Success[T],
    executor: ExecutionContext): Future[T]    

The previous three categories of retry attempts, retry.Directly, retry.Pause, and retry.Backoff, now define methods which produce retry.Policies. Your applications can then be free to mix and match retry policies as seen fit.

retry forever

It was previously only possible to retry for a finite number of times. Sometimes you want to try, try, and try again until your future arrives at a succesful conclusion. Each of the 3 retry modules now expose a forever method that will keep retrying until a successful result is produced using semantics tied to the type of retry.

// retry pausing 1 second forever until tryHarder tries hard enough
val forever = retry.Pause.forever(1.second)
val future = forever(tryHarder)

Odelayed retries

The platform hooks for scheduling future retries at a later time was refactored out into its own library, odelay. Hence, this version of retry no longer requires multiple modules. Retry as a library is only responsible for providing retry logic, relying on odelay for future retry scheduling. Retries which previously required an retry.Timer in implicit scope now require an implicit odelay.Timer.

A new module name

Since there is no longer any need for platform timer modules in retry, there is only one published module and it’s module name has be simplified to just “retry”.

resolvers += "softprops-maven" at "http://dl.bintray.com/content/softprops/maven"

libraryDependencies += "me.lessis" %% "retry" % "0.2.0"   

Successful composition

A library for retrying operations has a heavy interest understanding what it means to be “successful”. retry.Success is a type class for encoding the semantics for what a “success” means for your future. A retry.Success is still a retry.Success in this version. In this version, they are also more composable. A preference is also taken for the factory method for constructing new success instances. For illustration, see the example below

 // a future's value will be inferred as a success if its value is greater than one
 val a = Success[Int](_ > 1)
 // a future's value will be inferred as a success if its value is less then three
 val b = Success[Int](_ < 3)
 // a future's value will inferred as a success if its value is greater than one or less than three
 val either = a.or(b)
 // a future's value with be inferred as a success if its value is both greater than one and less than three
 val both = a.and(b)

This interface defines a simple algebra for Ints. Your application most like defines Futures which return a more complex type. Experiment with this new interface to compose different definitions of success for your applications types to enrich your retry experience.

If you are feeling adventurous, consider using retry.Success.always or retry.Success.never which will either infer success from any resulting value or no resulting value respectively.

re-determine how to retry When the right stars are in alignment

Sometimes things don’t go according to plan. Sometimes you are forced to share the wheel with “exceptional” code that expresses failure with fantastic runtime exceptions.

Sometimes you are working with a rate-limited service that will respond with a suggested time to come back knocking at a later time. For these types of usecases, retry exposes an adaptive interface called retry.When which takes a PartialFunction of Any to retry.Policy which allows you to adapt to any kind of failure you throw at it.

val policy = retry.When {
  case RetryAt(time) => retry.Pause(delay = time.seconds)

For more information see the project’s readme

retry is a library of abstractions for retrying failed scala.conncurrent.Futures


Permalink 1 note

20 7 / 2014

sbt-doge 0.1.1

sbt-doge is an sbt plugin for aggregating on crossScalaVersions on multi-project builds.

Imagine you have a multi-project build with libProj that cross publishes for Scala 2.10.4 and 2.11.1, and fooPlugin that publishes only for Scala 2.10.4. The root project might look something like this:

lazy val rootProj = (project in file(".")).
  aggregate(libProj, fooPlugin).
  settings(commonSettings: _*)

Unlike the built-in +compile, sbt-doge can partially cross build the aggregated subprojects, and skip 2.11.1 build of fooPlugin. Just run this from the shell:

> ;so clean; such test; very publishLocal

sbt-doge is an sbt plug-in that aggregates across corssScalaVersions for multi-project builds.

14 7 / 2014

scalikejdbc 2.0.5

ScalikeJDBC 2.0.5 is out.


ScalikeJDBC Logo



  • #264 Enable read config with defaults

Enjoy writing mostly type-safe SQL and get things done!

ScalikeJDBC is a tidy SQL-based DB access library for Scala.


Permalink 1 note

14 7 / 2014

odelay 0.1.0

initial release

Scala Futures are primitives for composing behavior over defered values. Odelay defines a set of primatives for composing behavior over operations delayed for FiniteDurations.

typical usage

import scala.concurrent.ExecutionContext.Implicits.global
import scala.concurrent.duration._
import odelay.Timer.default

// declare a delay
val delay = odelay.Delay(5.seconds) {

Delays define a future interface for projecting on the scheduling of an operation.

// project on a delay's success
delay.future.onSuccess {
  case result => println("operation was scheduled")

Unlike scala Futures, Delays may explicitly be cancelled. A Delay may also project on a cancelation state by reacting to its future’s failure state.

// project on a delay's cancellation
delay.future.onFailure {
  case _ => println("operaton was cancelled")


Odelay also supports periodic repeating operations.

// run myDelatedOperation every 5 seconds with no initial delay
val periodic = odelay.Delay.every(5.seconds)() {

See the project’s readme for more examples.


Odelay defines a Timer interface responsible for delay scheduling. Timer’s are defined for various backends: Jdk ScheduledExecutorSerivces, Netty HashWheeledTimers, and Twitter-util’s timer’s. A jdk Timer is used by default. Swap in a runtime specific module to use Netty{3,4} or Twitter Timers.

See the project’s readme for a more in-depth overview of Timers

odelay defines a set or primitives for delaying operations and reacting to their execution


Permalink 1 note

08 7 / 2014

bintray-sbt 0.1.2


  • published artifacts now use the moduleName sbt setting rather than name. This fixes some normalization when you specify unconventional project names.


The general theme for this release is to reduce publishing pain for those who have special publishing needs. Bintray.com reduces this pain rather well. Bintray-sbt exposes those pain killers to your sbt build.

  • PGP sign your published artifacts remotely

PGP is an industry standard for signing your work in a way that can be verified by interested parties. You can now store you PGP credentials on bintray so that you can sign artifacts from anywhere. Once you’ve uploaded your PGP keys to bintray’s servers, you can sign your published artifacts with the remoteSign sbt task ( your pgp passphrase is required )


Note, this is a voluntary action. It does not run when you publish, run the publish task first, then run remoteSign. This action will publish the signed artifacts for the current version. Note that if you want to sign your artifacts locally rather than remotely, there’s a well-maintained sbt plugin for that as well.

  • sync to maven central

Bintray.com puts you at the center of control for publishing arbitrary content, including maven artifacts. Because bintray decentralizes published content, it’s host’s are most likely not in the default resolver chains of most build tools, including sbt. Until then, your users will have to append a bintray resolver for your artifacts. To address this, bintray now supports maven central synchronizing of artifacts for those who’s bintray packages are linked to jCenter and who have a registered account on sonatype oss.

To have your bintray-published artifacts sync’d with maven central, you can simply run the syncMavenCentral task ( user sonatype credentials are required if you don’t have a set of sbt publishing credentials already defined for the “oss.sonatype.org” host)


Note, this is a voluntary action. Syncing packages to maven central has some extra requirements. Most are covered in the article here and here.

  • convenience for maven repo convention

Typical bintray usage in sbt will be resolving packages from maven repositories. To append a bintray resolver in sbt you could previously add the following to your build definition

resolvers += bintray.Opts.resolver.repo("user", "maven")

The bintray convention of storing maven style packages in a bintray repo named “maven” is not likely to change so in most cases you may now wish to simply use the following in your build definition

resolvers += bintray.Opts.resolver.mavenRepo("user")

bintray-sbt brings publishing back to your console.

08 7 / 2014

bintry 0.3.0


Enjoy Bintray’s new syncing feature. Note, you may need to adjust your build definition to meet the requirements for a maven central sync.

import bintry._
Client(user, pass).repo(sub, repo)
  .mavenCentralSync(sonauser, sonapassword)()

Feel at ease with Bintray’s hosted pgp signing feature

import bintry._
Client(user, pass).repo(sub, repo)
  • Added support for downloading logs and pulling down a download

bintry is an interface for interacting with and publishing to bintray.com

07 7 / 2014

scoobi 0.8.5

Maintenance version


  • using wire formats to serialise DObjects
  • added a WireFormat for java.util.Map[A, B]
  • set the classpath diagnostics as debug info on the client by default
  • simplified the use of overwritable text file output format
  • added an overwritable text file sink
  • added the possibility to fully specify the temp directory with scoobi.workingdir and scoobi.tempdir
  • display only the sink id when pretty printing the graph
  • added methods to use an Emitter in the combine phase
  • added the possibility to use the task input output context in a parallelDo
  • added the possibility to access the configuration from a map operation
  • throw an exception if the compression codec is not available added a method to check the availability of a codec
  • added a “download” sink to collect downloaded files in map tasks


  • fixed the passing of WireFormat when transforming a Combine node in a ParallelDo
  • fixed the numbering of steps
  • set the configuration if possible on the codec before getting its compressor
  • fix for checkpoints when one job fails In that case the _SUCCESS_JOB file for the other job is not changed into _SUCCESS but we should still use the checkpoint if there is one

scoobi is a productivity library for writing Hadoop jobs in Scala.

For more information visit: http://nicta.github.com/scoobi.

07 7 / 2014

specs2 2.3.13

Maintenance version


  • defaulting to displaying the full class name of a class if the simple class name doesn’t work (in the console sometimes)
  • copy system properties in an immutable map to avoid CMEs #264
  • avoid NPE when an exception with no message is caught on class instantiation #265
  • fixed the .await method for future matchers and failed futures #269
  • output the full class name of a class in the junitxml path #273
  • fixed the inOrder matcher for the allOf container matcher
  • deal with duplicated lines in haveSameLinesAs #276
  • added back a missing conversion method for AsResult instances This allows to write List(1 must_== 1, 1 must_== 1)


specs2 is a library for writing software specifications in Scala.

For more information visit: http://specs2.org.

06 7 / 2014

courier 0.1.3



  • #7 added documentation on testing mcamou


  • dropped scala 2.9.3 support, added scala 2.11 support

courier delivers electronic mail in scala