You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@daffodil.apache.org by Mike Beckerle <mb...@apache.org> on 2022/11/30 14:47:32 UTC
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 <mb...@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?
>
Re: new daffodil module to reduce regression testing difficulties ?
Posted by Steve Lawrence <sl...@apache.org>.
Yep, that should be all that's needed.
I believe IntelliJ just uses the sbt server under the hood, so things
should "just work". We won't know for sure until we test it, but we use
plugins for other things (e.g. sbt-cc, native-packager) that I assume
work find with IntelliJ.
On 11/30/22 5:02 PM, Mike Beckerle wrote:
> If we make this an sbt plugin, then one would add a daffodil plugin to a
> plugins.sbt in the project directory yes?
>
> Along the lines of adding this line to each schema projects'
> project/plugins.sbt
>
> addSbtPlugin("org.apache.daffodil" % "daffodil-sbt-plugin" % "3.5.0")
>
> This would need to be updated to change daffodil releases, rather than
> editing versions of library dependencies in the build.sbt file.
>
> Do I have that about right?
>
> I am concerned about IntelliJ IDEA integration - I still want it to work
> smoothly for IntelliJ IDEA to be able to discover the dependencies and
> classpath so that one can easily debug.
>
>
>
>
> On Wed, Nov 30, 2022 at 11:26 AM Davin Shearer <sc...@gmail.com>
> wrote:
>
>> 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 <mb...@apache.org>
>> wrote:
>>
>>> I never got any feedback on this idea. Thoughts? Observations?
>>>
>>> On Tue, Nov 1, 2022 at 11:17 AM Mike Beckerle <mb...@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?
>>>>
>>>
>>
>
Re: new daffodil module to reduce regression testing difficulties ?
Posted by Mike Beckerle <mb...@apache.org>.
If we make this an sbt plugin, then one would add a daffodil plugin to a
plugins.sbt in the project directory yes?
Along the lines of adding this line to each schema projects'
project/plugins.sbt
addSbtPlugin("org.apache.daffodil" % "daffodil-sbt-plugin" % "3.5.0")
This would need to be updated to change daffodil releases, rather than
editing versions of library dependencies in the build.sbt file.
Do I have that about right?
I am concerned about IntelliJ IDEA integration - I still want it to work
smoothly for IntelliJ IDEA to be able to discover the dependencies and
classpath so that one can easily debug.
On Wed, Nov 30, 2022 at 11:26 AM Davin Shearer <sc...@gmail.com>
wrote:
> 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 <mb...@apache.org>
> wrote:
>
> > I never got any feedback on this idea. Thoughts? Observations?
> >
> > On Tue, Nov 1, 2022 at 11:17 AM Mike Beckerle <mb...@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?
> > >
> >
>
Re: new daffodil module to reduce regression testing difficulties ?
Posted by Davin Shearer <sc...@gmail.com>.
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 <mb...@apache.org> wrote:
> I never got any feedback on this idea. Thoughts? Observations?
>
> On Tue, Nov 1, 2022 at 11:17 AM Mike Beckerle <mb...@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?
> >
>
Re: new daffodil module to reduce regression testing difficulties ?
Posted by Steve Lawrence <sl...@apache.org>.
> 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 <mb...@apache.org>
> Sent: Wednesday, November 30, 2022 9:48 AM
> To: dev@daffodil.apache.org
> 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 <mb...@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?
>>
RE: new daffodil module to reduce regression testing difficulties ?
Posted by "Interrante, John A (GE Research, US)" <Jo...@ge.com>.
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 <mb...@apache.org>
Sent: Wednesday, November 30, 2022 9:48 AM
To: dev@daffodil.apache.org
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 <mb...@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?
>