scala, maven, and netbeans

I’ve been coding scala using TextMate with ant or simple-build-tool, but I’d like to give NetBeans a try again. Coding without IDE wasn’t as bad, since the compiler and tests can catch undefined symbols and typos while making code changes; however, that’s not to say it was perfect. I had to go back and forth between the scaladoc and TextMate in situation I could have just let IDE autocompletion look things up. Also navigating between error messages and the code has been slow, especially since I moved to sbt, which is not integrated with TextMate.

parsing parameter using scopt

Of three command line parameter parsing libraries that I found in Scala, I found jstrachan/scopt to be the best one out there: lightweight and easy to use. The new feature I will be working on, however required -x:key=value option, which was not supported by scopt. The great thing about opensource is that I can just add the new feature if I want to, and github makes it so easy to fork and add a few things in.

simple-build-tool (sbt) and scala bazaar system (sbaz)

Now that I could compile files and evaluate thing from specs, I wanted to create a sbaz package to completely replace Ant.

These Ant tasks are implemented in compiler jar as scala code, so all I had to do was port them over to sbt task. Ant scalascript task generates a shell script that runs you application, which became ScalaScriptTask.scala. Ant sbaz task generates sbaz package, which is a zip file with description in it as an xml file, which became ScalaBazaarTask.scala.

simple-build-tool (sbt) and specs

somewhat updated

Some people land on this page searching for “sbt specs” on Google, so I feel somewhat obligated to update the info on this page.

First of all, as of 2011, the specs signature in Project file looks like:

    val specsVersion = crossScalaVersionString match {
      case "2.8.0" => "1.6.5"
      case _ => "1.6.6"
    }
    val specs = "org.scala-tools.testing" % ("specs_" + crossScalaVersionString) % specsVersion % "test"

Next, I was fitting integration test into specs, but it really should be used for writing BDD style test like the following:

hitting some scala limitations

Fixing salaxb so it can compile Footprint XML Specification.

First I had to account for the fact that in XML Schema, you could legally have elements having the same name as long as they are not at the top level. This required me to change the parsing a little bit. Next, I was fixing the simple content handling, I ran into the following error message by Scala compiler:

[scalac] tests/tmp/footprint.scala:255: error: value Tuple23 is not a member of package scala 
   [scalac] case class VolunteerOpportunity(volunteerOpportunityID: Option[String],
   [scalac]            ^
   [scalac] one error found

This is because Scala supports only up to Tuple22.

understanding xml schema complex types

There’s a great article about XML Schema called Understanding W3C Schema Complex Types by Donald Smith. I wish I’ve read this earlier. The author summarizes the complex types into four simple points:

• derivation (restriction, extension, list, and union) is the basis of connection between types in the type hierarchy.
• the initial branching of the hierarchy is into simple and complex types.
• while both forms of complex type allow attributes, only those with complex content allow child elements; those with simple content only allow character content.
• the default syntax for complex types is complex content that restricts anyType.