implicit.ly

Scala software, hot off the presses

Grizzled SLF4J 0.6.2

  • Per a suggestion from Josh Suereth, the Logging class's methods are now marked @inline and final, allowing the Scala compiler to pull them inline, if it can, for greater efficiency.

The Grizzled SLF4J package provides a very thin Scala-friendly layer on top of the SLF4J (Simple Logging Facade for Java) API.

Filed under  //   Grizzled SLF4J   Scala 2.7.7   Scala 2.8.0   Scala 2.8.1   Scala 2.9.0   Scala 2.9.0-1   org.clapper  

Grizzled SLF4J 0.6.1

  • Updated SBT build file so that published Maven POM lists the slf4j-api dependency as "provided". This change addresses Grizzled SLF4J Issue #3.

The Grizzled SLF4J package provides a very thin Scala-friendly layer on top of the SLF4J (Simple Logging Facade for Java) API.

Filed under  //   Grizzled SLF4J   Scala 2.7.7   Scala 2.8.0   Scala 2.8.1   Scala 2.9.0   Scala 2.9.0-1   org.clapper  

Grizzled SLF4J 0.6

  • Now builds against Scala 2.9.0-1, as well as Scala 2.9.0, 2.8.1, 2.8.0 and 2.7.7.
  • Converted to build with SBT 0.10.1

The Grizzled SLF4J package provides a very thin Scala-friendly layer on top of the SLF4J (Simple Logging Facade for Java) API.

Filed under  //   Grizzled SLF4J   Scala 2.7.7   Scala 2.8.0   Scala 2.8.1   Scala 2.9.0   Scala 2.9.0-1   org.clapper  

Unfiltered 0.3.4

  • chrislewis NotFoundHandler added as last in pipeline; plans push unhandled requests upstream. Channel handlers plans can now be chained like filter plans.
  • softprops Refactor of WebSockets interface, now enables the use of Unfiltered's request extractors prior to the WebSockets handshake. See the module's readme for details and examples.
  • Compiled, tested, and published for all release versions of Scala from 2.7.7 to 2.9.0-1.

Unfiltered is a toolkit for servicing HTTP requests in Scala.

scopt 1.1.0

  • Adds argOpt and arglistOpt method for optional arguments.

scopt is a little command line options parsing library.

Filed under  //   Scala 2.7.7   Scala 2.8.0   Scala 2.8.1   Scala 2.9.0-1   com.github.scopt   scopt  

scopt 1.0.0

hello, world

This is the initial release of scopt, a little command line parsing library.

You can customize an OptionParser by passing in functions to process each option or argument.

val parser = new OptionParser("scopt") {
  intOpt("f", "foo", "foo is an integer property", {v: Int => config.foo = v})
  opt("o", "output", "<file>", "output is a string property", {v: String => config.bar = v})
  booleanOpt("xyz", "xyz is a boolean property", {v: Boolean => config.xyz = v})
  keyValueOpt("l", "lib", "<libname>", "<filename>", "load library <libname>",
    {(key: String, value: String) => { config.libname = key; config.libfile = value } })
  arg("<singlefile>", "<singlefile> is an argument", {v: String => config.whatnot = v})
  // arglist("<file>...", "arglist allows variable number of arguments",
  //   {v: String => config.files = (v :: config.files).reverse })
}
if (parser.parse(args)) {
   // do stuff
}
else {
  // arguments are bad, usage message will have been displayed
}

It handles various kinds of options such as optional, required, and key-value. From the above, it also automatically generates the usage text as follows:

Usage: scopt [options] <filename>

  -f <value> | --foo <value>
        foo is an integer property
  -o <file> | --output <file>
        output is a string property
  --xyz <value>
        xyz is a boolean property
  -l:<libname>=<filename> | --lib:<libname>=<filename>
        load library <libname>
  <singlefile>
        <singlefile> is an argument

scopt is a little command line options parsing library.

Filed under  //   Scala 2.7.7   Scala 2.8.0   Scala 2.8.1   Scala 2.9.0-1   com.github.scopt   scopt  

grizzled-slf4j 0.5

  • Updated to build against Scala 2.9.0, as well as the 2.7 and 2.8 series.

The Grizzled SLF4J package provides a very thin Scala-friendly layer on top of the SLF4J (Simple Logging Facade for Java) API.

Filed under  //   Scala 2.7.7   Scala 2.8.0   Scala 2.8.1   Scala 2.9.0   grizzled-slf4j   org.clapper  

Unfiltered 0.3.3

Documentation

Unfiltered documentation is now available.

library module

  • eed3si9n Accepts.Javascript now accepts text/javascript or application/javascript
  • eed3si9n Accepts.Jsonp now accepts application/json, text/javascript, or application/javascript
  • Deprecating HttpRequest.requestURI and HttpRequest.contextPath and replacing with HttpRequest.uri. HttpRequest.contextPath only existed to suit the HttpServletRequest spec and had no context in the Netty module and thus should not be in the base HttpRequest interface.
  • Added QueryString(qs) extractor for extracting the raw query string from a request
  • Added HostPort(hostname, port) extractor for extracting out a request's host and port
  • New unfiltered.request.Body object for working with request bodies explicitly, not as an extractor as these operations generally have side effects.

json-p

eed3si9n The Jsonp wrapper object now defines a respond method that returns a ChainResponse that handles a by-name parameter which produces a lift-json JValue.

case GET(UFPath("/jsonp/lift-json/optional") & Jsonp.Optional(callback)) => callback respond {
  import net.liftweb.json.JsonAST._
  import net.liftweb.json.JsonDSL._
  "answer" -> Seq(42)
}

filter module

  • Added ContextPath(ctx, path) extractor to suit filter plans mounted on a context path. Note, the Path extractor will contain the context path. To remove redundancy in filter plans, use ContextPath(ctx, path)

Prior to this release, you used matched filters on context paths with

jettySvr.context("/foo") { _.filter(Planify { case Path("/bar") => ... } }

To accomplish the same match in this release and beyond,

jettySvr.context("/foo") { _.filter(Planify { case ContextPath(_, "/bar") => ... } }

netty module

  • gh-15 Fixed issue with undecoded parameter keys

all intents

A function object Intent#apply to filter and other intent types, to explicitly construct an intent without the somewhat awkward type annotations.

val anIntent = unfiltered.filter.Intent {
  case GET(req) => ...
}

Unfiltered is a toolkit for servicing HTTP requests in Scala.

sbt-cloudbees-plugin 0.2.7

Now supporting delta-updates of WAR files. This slashes the amount of time it takes to deploy a file to Run@Cloud to a few seconds.

Changes:

  • Added new control "beesShouldDeltaWar". If for some reason you don't want to use the delta WAR functionality then you should just set override def beesShouldDeltaWar = false within your project file.

CloudBees Run@Cloud SBT Plugin

Integration for SBT that lets you deploy apps to the CloudBees RUN@Cloud PaaS

Usage

Firstly, you need to grab the key and secret from grandcentral.cloudbees.com, which should look like:

Grand Central Keys

Once you have these two values, you can do one of two things:

  • Enter them when the plugin prompts you; this will be on everytime you run a deployment to the cloud
  • Create a properties file called bees.config in $HOME/.bees/ so that you only need to define them once per computer. This properties file needs to be a key-value pair style like this:
bees.api.key=XXXXXXXXXX
bees.api.secret=XXXXXXXXXXXXXXXXXXXXXXXXXXXXX=

Whichever route you choose to specify that information, you then only need to define the plugin information in any given project. Specifically, in the Plugins.scala file define the following:

import sbt._
  class Plugins(info: ProjectInfo) extends PluginDefinition(info) {
    lazy val cloudbees = "eu.getintheloop" % "sbt-cloudbees-plugin" % "0.2.6"
    lazy val sonatypeRepo = "sonatype.repo" at "https://oss.sonatype.org/content/groups/public"
  }

Add the plugin to your SBT project like so:

import sbt._
  class YourProject(info: ProjectInfo) extends DefaultWebProject(info) with bees.RunCloudPlugin {
    ....
    override def beesApplicationId = Some("whatever")
    override def beesUsername = Some("youruser")
  }

Again, if you would prefer to enter these values when you deploy your application then you can of course just enter the appropriate values when prompted. Now your all configured and good to go, there are two commands you can run with this plugin:

  • Get a list of your configured applications: bees-applist
  • Deploy your application bees-deploy

Filed under  //   Scala 2.7.7   eu.getintheloop   sbt-cloudbees-plugin  

sbt-cloudbees-plugin 0.2.6

After stax.net was acquired by CloudBees it made sense to move to the new endpoints etc to ensure on-going usefulness of the plugin in case the stax.net endpoints are ever decommissioned. This version is a complete rewrite from the previous version.

Changes:

  • If any configuration parameter is not defined, the plugin auto-prompts you for it
  • Now deploy your application with "bees-deploy" in place of "stax-deploy"
  • Rename your staxApplicationId to beesApplicationId
  • Rename your staxUsername to beesUsername

CloudBees Run@Cloud SBT Plugin

Integration for SBT that lets you deploy apps to the CloudBees RUN@Cloud PaaS

Usage

Firstly, you need to grab the key and secret from grandcentral.cloudbees.com, which should look like:

Grand Central Keys

Once you have these two values, you can do one of two things:

  • Enter them when the plugin prompts you; this will be on everytime you run a deployment to the cloud
  • Create a properties file called bees.config in $HOME/.bees/ so that you only need to define them once per computer. This properties file needs to be a key-value pair style like this:
bees.api.key=XXXXXXXXXX
bees.api.secret=XXXXXXXXXXXXXXXXXXXXXXXXXXXXX=

Whichever route you choose to specify that information, you then only need to define the plugin information in any given project. Specifically, in the Plugins.scala file define the following:

import sbt._
  class Plugins(info: ProjectInfo) extends PluginDefinition(info) {
    lazy val cloudbees = "eu.getintheloop" % "sbt-cloudbees-plugin" % "0.2.6"
    lazy val sonatypeRepo = "sonatype.repo" at "https://oss.sonatype.org/content/groups/public"
  }

Add the plugin to your SBT project like so:

import sbt._
  class YourProject(info: ProjectInfo) extends DefaultWebProject(info) with bees.RunCloudPlugin {
    ....
    override def beesApplicationId = Some("whatever")
    override def beesUsername = Some("youruser")
  }

Again, if you would prefer to enter these values when you deploy your application then you can of course just enter the appropriate values when prompted. Now your all configured and good to go, there are two commands you can run with this plugin:

  • Get a list of your configured applications: bees-applist
  • Deploy your application bees-deploy

Filed under  //   Scala 2.7.7   eu.getintheloop   sbt-cloudbees-plugin