I never got any feedback on this idea. Thoughts? Observations? On Tue, Nov 1, 2022 at 11:17 AM Mike Beckerle <mbecke...@apache.org> 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? >
