As rulewerk usage picks up, I expect to see more issues of the form #175, which need access to both a reasoner backend and to the parser to faithfully reproduce. Currently, neither of rulewerk-vlog and rulewerk-parser depends on the other, and I would prefer to keep it that way.
Hence, the proposal is to add another maven module integrations that can freely depend on the other modules and would only contain tests. Like the coverage module, it would not produce a releasable artifact (note that we can't reuse the coverage module for the integration tests, because we want to keep the integration test coverages separate from the unit test coverages).
Prime candidates for moving to the integrations module would be
[ ] a regression test for #175,
[ ] the tests in rulewerk-vlog that use the rulewerk-rdf module, so that we can drop the test dependency (cf. #127),
[ ] serialisation/parsing round-tripping tests (cf. comments in #149), and
[ ] the class VLogRegressionTest in rulewerk-vlog, which would be much more readable if it could use the parser.
As rulewerk usage picks up, I expect to see more issues of the form #175, which need access to both a reasoner backend and to the parser to faithfully reproduce. Currently, neither of
rulewerk-vlog
andrulewerk-parser
depends on the other, and I would prefer to keep it that way.Hence, the proposal is to add another maven module
integrations
that can freely depend on the other modules and would only contain tests. Like thecoverage
module, it would not produce a releasable artifact (note that we can't reuse thecoverage
module for the integration tests, because we want to keep the integration test coverages separate from the unit test coverages).Prime candidates for moving to the
integrations
module would berulewerk-vlog
that use therulewerk-rdf
module, so that we can drop the test dependency (cf. #127),VLogRegressionTest
inrulewerk-vlog
, which would be much more readable if it could use the parser.