[
https://issues.apache.org/jira/browse/DAFFODIL-2697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Interrante updated DAFFODIL-2697:
--------------------------------------
Description:
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?
was:
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?
> 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
> Priority: Minor
>
> 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)
