| Re: [papyrus-rt-dev] Test models |
|
Hi Ernesto, We are not using these models on the tooling part, so there is no issue reorganizing them. While I am working on the terminology update, I became more and more sensitive to the labels ;) I would advise not to go for ‘statemach’, but rather ‘statemachine’,
for the same reasons invoked in the bug on profile renaming [1]. Regards, Rémi [1] 491235: [Terminology] Decide on a common and aligned UML-RT related terminology in Papyrus-RT https://bugs.eclipse.org/bugs/show_bug.cgi?id=491235 ------------------------------------------------------- Rémi SCHNEKENBURGER +33 (0)1 69 08 48 48 CEA Saclay Nano-INNOV Institut CARNOT CEA LIST De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx]
De la part de Ernesto Posse Hello team. Is anyone other than us (working on codegen) using the models under models/tests? I'd like to reorganize these tests, and I've pushed change
77856 to gerrit with my proposed reorganization. Are there any objections to this? The folders are described below. We could add folders to deal with tooling, validation or migration as well. Any thoughts? Models are now organized into several sub-folders within models/tests: * executable: this should contain models which are "complete" in the sense that they correctly generate code which compiles and executes. *
codepattern: this contains models that are not necessarily intended to generate executable code, but rather they are intended to test the output produced by the code generator. It is split into the following sub-folders:
- general: contains models that deal with general features, such as different kinds of
inter-element references and dependencies.
- structure: contains models that exercise the structural code generators (Capsules, Protocols)
- statemach: contains models that exercise the state machine generator
- rtcppproperties: contains models that exercise the RtCppProperties generation profile * deprecated: contains older models that may have errors * other: contains models not classified in the above hierarchy. -- Ernesto Posse Zeligsoft |
