I really like this idea of centralizing a test framework for DFDL schemas for all the reasons you mentioned. It would also serve to help structure DFDL repositories, reduce burden on schema authors, and institute best practices.
On Wed, Nov 30, 2022 at 9:48 AM Mike Beckerle <[email protected]> wrote: > I never got any feedback on this idea. Thoughts? Observations? > > On Tue, Nov 1, 2022 at 11:17 AM Mike Beckerle <[email protected]> > wrote: > > > 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 suppose our new module is named > > daffodil-schema-sbt-test. > > > > 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? > > >
