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