[
https://issues.apache.org/jira/browse/DAFFODIL-2697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Thompson closed DAFFODIL-2697.
-----------------------------------
Verified the specified commits (commit
0f5ebcab73bc54394e58597b6e44d36ddfbfd8ee) is included in the latest pull from
the daffodil repository.
Verified changes identified in commit comments were implemented.
Verified DAFFODIL-2704. Verified all daffodil subproject sbt test suites
execute successfully without hanging. Exicuted each daffodil sub-projects sbt
test suite multiple time without the tests hanging, including
daffodil-tdml-processor.
> Choose TDML implementation to run TDML tests
> --------------------------------------------
>
> Key: DAFFODIL-2697
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2697
> Project: Daffodil
> Issue Type: Improvement
> Components: CLI, TDML Runner
> Reporter: John Interrante
> Assignee: Dave Thompson
> Priority: Minor
> Fix For: 3.4.0
>
>
> h2. New description
> Add TDML implementation option to Daffodil's CLI test subcommand and extend
> Runner API with TDMLImplementation parameter (defined by dafext.xsd) to allow
> running the same TDML file with any specified TDMLImplementation without
> having to change the TDML file. Run runtime2 TDML and Scala tests with
> TDMLImplementation specified through Runner API, not tunable.
> Also fix some inconsistencies with fill bits overlooked by a previous pull
> request which extended runtime2 to read and write N-bit numbers.
> h3. Original description (outdated)
> It would be very nice if we could run the same TDML file with either runtime1
> or runtime2 without changing the TDML file. Right now the only way to run a
> TDML file or test with runtime2 is to define a "runtime2" config (which could
> be a file or an embedded config) and use it in either
> defaultConfig="runtime2" on the TDML file or config="runtime2" on the TDML
> test. Is there any reason why the daffodil test subcommand can't accept the
> same `-c, --config <file>` and `-Ttunable=value` options as most of the other
> subcommands, build a tunables object, and pass it to the Runner? Most of the
> other subcommands pass a tunables object from the CLI to the rest of
> Daffodil, but I read a comment on DFDLTestSuite that says
> {noformat}
> * Keep this independent of Daffodil, so that it can be used to run tests
> against other DFDL implementations as well.
> * E.g., it should only need an API specified as a collection of Scala
> traits, and some simple way to inject
> * dependency on one factory to create processors.{noformat}
> Can the CLI still pass a tunables object explicitly to DFDLTestSuite anyway,
> or pass it implicitly somehow?
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
