Extract compliance tool to be its own package #245
Conversation
We extract the compliance_tool into its own package, since the functionality is not needed in the general SDK anymore. The new aas-compliance-tool can be found [here](https://github.com/rwth-iat/aas-compliance-tool).
When we removed the schema files, we overlooked that JSON and XML serialization need them. We probably need to find a way of fetching them during runtime of the test to avoid having to host them in our repository.
s-heppner
force-pushed
the
Extract/ComplianceTool
branch
from
69cc218
to
d5af8aa
Compare
This removes the JSON Schema and XSD files that stem from the aas-specs repository. Instead, this adds the logic in the CI to fetch these files at runtime. Furthermore, we skip the unittests that make use of the schema files when they do not exist.
|
Hmm, this also removes all compliance tool tests. I thought it would be good to install the compliance tool via pip for our CI, but now that I think about it, it doesn't make sense as this test would always fail when changing something essential, e.g. when updating to DotAAS v3.1 eventually, as the compliance tool is only updated after the SDK. |
|
I think it's acceptable for these tests to be removed. Our next release will still be v3.0 of the metamodel and before we implement v3.1, we will switch to the classes from aas-core. |
|
Yes, but the adapters are still implemented manually and would remain untested. If aas-core provides a set of testfiles for JSON/XML/AASX this is fine. |
|
No, the adapters are also part of aas-core: We've already experimented with encapsulating with our functions to avoid breaking changes and it should work. The way the SDK are tested, to my understanding, is using them to serialize and deserialize the generated example files from aas-core-testgen and then comparing the result, so it should be equivalent, or even better than our current tests. However, I would still advocate to implement #109 in the future for further peace of mind that our modifications did not mess up anything. |
We extract the compliance_tool into its own
package, since the functionality is not needed
in the general SDK anymore.
When we removed the schema files, we overlooked
that JSON and XML serialization need them.
We probably need to find a way of fetching
them during runtime of the test to avoid having
to host them in our repository.
The new aas-compliance-tool can be found
here, when the process is finished.
The released package can be found on PyPI
The following steps still need to be done: