> We might need to use a SBT plugin rather than a SBT module to achieve
such an effect.
I was thinking this exact thing. A "DFDL Schema" sbt plugin is probably
the best way to remove alot of this dependency duplication. Plugin
settings could also be used to enable/disable things like the flat
directory structure, specify which Daffodil version to use, etc.
And since this plugin wouldn't do anything fancy aside from override
existing settings, it should be relatively straightforward to implement.
It could also be extended to add additional capabilities in the future,
like add a command to run IBM tests.
On 11/30/22 10:22 AM, Interrante, John A (GE Research, US) wrote:
I believe both Maven and SBT handle transitive dependencies similarly? My own
build.sbt for schema projects has 4 dependencies, all of which are test-only
dependencies:
scalaVersion := "2.12.17"
libraryDependencies ++= Seq(
"com.github.sbt" % "junit-interface" % "0.13.3" % "test",
"junit" % "junit" % "4.13.2" % "test",
"org.apache.daffodil" %% "daffodil-tdml-processor" % "3.4.0 " % "test",
"org.apache.logging.log4j" % "log4j-core" % "2.19.0" % "test",
)
We can't just move these test-only dependencies to daffodil-schema-sbt-test without changing their
scope, because Maven and probably SBT too won't create transitive dependencies on another module's
test dependencies. We would have to replace these "test" scopes with "compile"
scopes to turn them into transitive dependencies which we could bring in just by using one line:
libraryDependencies := Seq(
"org.apache.daffodil" %% "daffodil-schema-sbt-test" % "3.4.0" % "test"
)
I'm not sure how many other lines we can move from your build.sbt to
daffodil-schema-sbt-test too? It would be ideal if we could somehow make all
these lines in a build.sbt for schema projects unnecessary:
scalaVersion := "2.12.17"
testOptions += Tests.Argument(TestFrameworks.JUnit, "-v")
crossPaths := false
// Use flat folder structure. This means *.java and *.scala files are in the
// same directory as resources files, and source/resource files are only
// differentiated by their file extension.
Compile / unmanagedSourceDirectories := Seq(baseDirectory.value / "src")
Compile / unmanagedResourceDirectories := Seq(baseDirectory.value / "src")
Compile / unmanagedSources / includeFilter := "*.java" | "*.scala"
Compile / unmanagedResources / excludeFilter := "*.java" | "*.scala"
Test / unmanagedSourceDirectories := Seq(baseDirectory.value / "test")
Test / unmanagedResourceDirectories := Seq(baseDirectory.value / "test")
Test / unmanagedSources / includeFilter := "*.java" | "*.scala"
Test / unmanagedResources / excludeFilter := "*.java" | "*.scala"
We might need to use a SBT plugin rather than a SBT module to achieve such an
effect.
John
-----Original Message-----
From: Mike Beckerle <[email protected]>
Sent: Wednesday, November 30, 2022 9:48 AM
To: [email protected]
Subject: EXT: new daffodil module to reduce regression testing difficulties ?
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?
