Where to place the annotations

ESROCOS / tools-transformation_modelling

Tool for parsing transformation annotations, modelling and analyzing

2 stars 0 forks source link

Where to place the annotations #2

Open Kynneb opened 6 years ago

Kynneb commented 6 years ago

Another question is where to place the annotations. Possibilities include

the AADL files (interfaceview) of the components: Could even be supported in TASTE and would not require yet another file artifact, requires an AADL parser (but that might be needed in other projects anyway. Probably would require an own format. (see #1 ) Obvious con: would bind annotation to esrocos/taste environment
The manifest.xml: Would fixate #1 on xml, would require manual entries in the file
An own "transformations" file: Pro: independent of taste/esrocos or even autoproj and would allow for arbitray format. Con: Yet another file to manually add and edit

saarnold commented 6 years ago

+1 for own transformation file

Kynneb commented 6 years ago

Would be my favourite, too.

Second question: Where to put those file(s)? In esrocos the way to go would be to have components developed individually in a singular project and then integrate them in a different project. In that case it would make sense to add a transformations file to each component and additional configuration (static transforms?) in the integration project. That would mean finding those files (via dependency list, presumably) and parsing them together.

But this leads to the question what is with (legacy / third party) components which don't bring such a file. Answer could either be to add that locally or to add the missing information to the integration projects transforms file.

Alternatively modelling could be done completely in one central file which would avoid the need for searching but decreases re-usability.

saarnold commented 6 years ago

I would prefer a centralized non-intrusive file. And this wouldn't exclude the possibility to support multiple files which can be merged by the parser.

Kynneb commented 6 years ago

Let's start with a centralized file and see if / when it makes sense to extract information to individual files.

I find the idea of having transformation provisions/requirements documented that way intriguing, but I agree that it should not be a requirement.

maltewi commented 6 years ago

+1 for own configuration file

rock has the ability to provide annotations on component level already. We should support that. I'll provde an example how this looks in rock.