scalaxb cli used -p and --package to specify both the default package name and namespace-specific package names. scalaxb 1.1.1 uses -p and --default-package for the default package; and --package for namespace-specific package names.
bug fixes and minor enhancements
Avoids type names that only differs in case. #215 reported by @drdozer
Fixes handling of xs:all with minOccurs=0 and nillable. #216 reported by @minettiandrea
Fixes xsi:nil="1" not parsed as nil. #217 reported by @aoprisan
scalaxb now generates sys.error, so the generated code will no longer be compilable under Scala 2.8. #115 reported by @idot and others.
dispatchVersion
A new key dispatchVersion was added to generate Dispatch 0.10.x compatible code #210:
dispatchVersion in scalaxb in Compile := "0.10.0"
libraryDependencies <+=(dispatchVersion in scalaxb in Compile) { dv =>
"net.databinder.dispatch" %% "dispatch-core" % dv
}
bug fixes and minor enhancements
Includes offending data in ParserFailure message. #206 requested by @caoilte
A few people have asked me on how to configure a sbt build so scalaxb can be used multiple times, so let’s take a look.
Here’s the code:
$ git clone -b multipleconfigs git://github.com/eed3si9n/scalaxb-sample.git
$ cd scalaxb-sample/multipleconfigs/
Now open the directory using your favorite editor.
In src/ we have main/scala/main.scala, main/xsd/ipo.xsd, and main/xsd/w.xsd.
when to go multiple configs?
With the single config approach, the xmlprotocol.scala contains the typeclass instances for all schemas. It’s currently necessary to compile all referenced schemas together, so normally that’s the route you should take.
In an effort to solve namespace conflicts and to increase consistency among the plugins, sbt plugins best practices was created. Here are the changes based on its recommendations:
keys are under ScalaxbKeys object
Keys provided by sbt-scalaxb now resides in ScalaxbKeys object. Place the following at the top of your build.sbt:
import ScalaxbKeys._
Scala identifiers for the keys remain the same (e.g. packageName), but key names accessible from the shell are now prefixed with scalaxb- (e.g. scalaxb-package-name).
settings are scoped under scalaxb task
scalaxb-specific settings are now scoped under scalaxb task. The default settings scalaxbSettings is scoped additionally by Compile configuration (no moreScalaxb configuration!).
seq(scalaxbSettings: _*)
packageName in scalaxb in Compile := "ipo"
sourceGenerators in Compile <+= scalaxb in Compile
If you wish to use scalaxb task multiple times in a project, you can do so by creating custom configurations in build.scala.
It seems I have inadvertently become “that guy who does SOAP with Scala”.
Also wanted to share a bit of the background. I’d known SOAP was doable because majority of the WSDL is actually XSD, and also @max4f has implemented it. But originally, I was going to wait a while till I implement WSDL/SOAP support. What got me moving quicker was @timperrett’s tweet on 4/26:
Has anyone ever built some kind of monadic abstraction on SOAP? If so, i want to hear your thoughts!
sbaz allowed quick installation of scalaxb, but it also had its share of problems like scala version dependencies and contaminating the REPL classpath.
Starting 0.6.1, scalaxb will no longer be supporting sbaz and recommend all users to switch to conscript for installing scalaxb.
$ sudo sbaz remove scalaxb
$ cs eed3si9n/scalaxb
no Array
xs:base64Binary now maps to scalaxb.Base64Binary instead of Array[Byte].
Both scalaxb.HexBinary and scalaxb.Base64Binary are backed by Vector[Byte] internally.
Other built-in types that previously mapped to Array[String] now maps to Seq[String].
During the .com boom, everyone has written a SOAP service or two, which were typically cataloged using WSDL. If you study a WSDL document, you’ll discover that a good portion of the document is actually embedded XML Schema document describing the layout of the messages sent back and forth. The rest are details. Since scalaxb is handling the XML Schema, it was only matter of time to extend this into supporting WSDL.
A big thanks to Max (@max4f) for writing a scalaxb plugin for sbt, and letting me pull it into the project.
If you’re not using simple build tool, why?
Here are the steps to compile-xsd task from sbt.
step 1. Plugins.scala
Add the following to your project/plugins/Plugins.scala.
import sbt._
classPlugins(info:ProjectInfo)extendsPluginDefinition(info){val scalaxb ="org.scalaxb"%"sbt-scalaxb"%"0.6.0"val scalaToolsNexusSnapshots ="Scala Tools Nexus Snapshots" at "http://nexus.scala-tools.org/content/repositories/snapshots/"val scalaToolsNexusReleases ="Scala Tools Nexus Releases" at "http://nexus.scala-tools.org/content/repositories/releases/"}