Over the years, SBT has become the standard for building and testing DFDL schemas. One problem we've come across is lot of boilerplate is needed to set up a schema, for example setting up dependencies, test options, directory layout. We've create the daffodil-schema.g8 repo to help with this, but it is still complex and is a manual process to update with newer versions of Daffodil.

We think an SBT plugin could help to solve this and more.

For one, it could provide all the common settings and dependencies the DFDL schemas have to copy/paste today. And updates to the plugin could update settings as well.

Additionally, we've found it can be difficult to create and distribute saved binaries in a repeatable and consistent way, especially considering binaries are Daffodil version specific. It would be much easier to run a task like "sbt packageDaffodilBin" to create these binaries. No need to setup classpaths or run the CLI, just a single command it it does everything. An SBT plugin could provide this functionality.

Similarly, one could imagine a custom sbt task to generate C code directly from the schema without having to using the CLI.

One could also imagine a plugin providing the ability to read TDML files and run tests directly from those without the need for associated junit Scala files, reducing boilerplate (though, this may have issues with IDE's).

Or the ability to enable coverage reports to determine how much of schema is actually used by TDML tests.

There are likely a number of other tasks an SBT plugin could add to make the lives of DFDL schema developers and users easier.


To solve some of these problems, Owl started development of an SBT plugin called "sbt-daffodil", with plans to make it publicly available. It currently only implements the ability to create and publish saved binaries, but we think it is at a good state where it makes sense to open source it--it provides stable and useful functionality, but is not too big yet.

And we think the Apache Daffodil project is the best place for it to live and continue development. Because it will want a separate release cycle from Daffodil, it probably also wants a separate repository, so I suggest we create a repo called:

  apache/daffodil-sbt

Once released, a DFDL schema repo could then add something like this to the plugins.sbt file and get all the settings and capabilities useful for a DFDL schema:

  addSbtPlugin("org.apache.daffodil" % "sbt-daffodil" % "1.0.0")

Any thoughts on future capabilities, an alternative approach, or objections to being part of Apache Daffodil at all? Giving the standard 72 hours for discussions, if there are no objections I'll go ahead and create the repo and create a pull request to start review on the current code.

- Steve

Reply via email to