I am having trouble regression testing schemas in bulk against the 3.4.0-RC1.

The challenge is that there are 70+ such schemas. All of them have
build.sbt which require updating, not just for the daffodil version
3.4.0 dependency, but for other dependencies that are no longer up to
date.

I have a suggestion.

In order to make it easy to test DFDL schemas against daffodil, and to
make the conflicting dependencies maintenance issue as simple as
possible, that we create a daffodil module named
daffodil-schema-sbt-test.

This module exists soley so that we have one single daffodil module
that a DFDL schema project can depend on, which drags in the
dependencies needed for testing a schema in the usual convenient sbt
manner.

The build.sbt for a DFDL schema would (usually) contain a single
dependency. For example:

name := "dfdl-jpeg"

organization := "com.mitre"

version := "0.0.1"

libraryDependencies := Seq(
  "org.apache.daffodil" %% "daffodil-schema-sbt-test" % "3.4.0" % "test"
)

That module's transitive dependencies would drag in, as dependencies,
scala and the scala library (I hope), as well as daffodil-tdml-lib,
junit-interface, junit, scala-xml, and any other modules that a schema
project might typically want to use but which are also possibly
conflicting dependencies in daffodil.

This way the DFDL schema would inherit the specific versions for those
dependencies from Daffodil, instead of stating them explicitly itself
which creates a maintenance problem.

Now, I'm not at all sure how to achieve this in sbt. But the build.sbt
for a DFDL schema really needs to be something that does NOT have a
bunch of modules/versions in it that require updating for each
daffodil release.

Thoughts?

Reply via email to