[
https://issues.apache.org/jira/browse/DAFFODIL-2697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17554543#comment-17554543
]
Dave Thompson commented on DAFFODIL-2697:
-----------------------------------------
Verified the specified commits (commit
382d870d640995bbb05280f3f5c1c1eb854aff71) is included in the latest pull from
the daffodil repository.
Verified changes identified in commit comments were implemented.
Verified affected daffodil subproject sbt test suites execute successfully,
including new and modified tests, with the exception of daffodil-io and
daffodil-tdml-processor.
The sbt test suite for daffodil-io hangs intermittently and the sbt test suite
for daffodil-tdml-processor hangs on every attempt.
After investigation with Steve it is determined that the hanging is caused by a
previous commit. FIRA ticket DAFFODIL-2704 was opened to cover the hanging
issue.
This ticket will be closed when DAFFODIL-2704 is resolved and all sub-project
sbt test suites execute without hanging.
> 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: John Interrante
> 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)
