search

osate / osate2

Open Source AADL2 Tool Environment
http://osate.org
Eclipse Public License 2.0
39 stars 8 forks source link

Property sets for AADL annexes #64

Closed yoogx closed 11 years ago

yoogx commented 12 years ago

OSATE does not have the property sets for the data modeling, ARINC653 and BA. It would be great to have them in the default install.

For the BA, having the property set should not be incompatible with any plug-in supporting it.

I may provide the corresponding file since we have them in Ocarina already, let me know

reteprelief commented 12 years ago

Lutz,

Jerome rings up an interesting question about property sets that come with annexes. People want to use those properties without necessarily using a plug-in to process them, for example, the data modeling properties.

We can just include them in the basic set, or use the annex mechanism to register them. What do you think?

A related issue is how to update/add new property sets to existing workspaces given the way they are made accessible. See also Issue 65.

Peter

-----Original Message----- From: Jerome Hugues [mailto:reply@reply.github.com] Sent: Friday, July 06, 2012 7:26 AM To: Peter Feiler Subject: [osate2-core] Property sets for AADL annexes (#64)

OSATE does not have the property sets for the data modeling, ARINC653 and BA. It would be great to have them in the default install.

For the BA, having the property set should not be incompatible with any plug-in supporting it.

I may provide the corresponding file since we have them in Ocarina already, let me know

Reply to this email directly or view it on GitHub: https://github.com/osate/osate2-core/issues/64

yoogx commented 12 years ago

Hi Lutz, Peter,

Do you have any recommendation for this issue, and issue 65? Thanks

reteprelief commented 12 years ago

Hi Jerome,

There are two kinds of annex contributions:

1) Property sets and packages: we have the predeclared ones and the SEI one. They can be used on core models and in annexes. They are registered by extension point org.osate.pluginsupport.aadlcontribution to become part of anyone’s workspace. The SEI property set for example is contributed via the org.osate.contributions.SEI plugin (the only thing it does). So we should provide the data modeling annex property set and package that way. Same with ARINC653.

2) A (sub) language extension: this requires a front-end to process annex libraries and subclauses. Examples are BA and Error Model. In this case we have additional extension points to register the elements of the frontend (parser/unparser). But such an annex can also have a property set. It can also be registered at the same time. Or does it make sense to register the property set separately, such that people have access to it without necessarily using the frontend to process the annex clauses. Where that would matter is when those properties are used/declared in the core part of the model.

I can add in the data model and ARINC property sets as such contribution. I just need to make sure I have the latest (correct ones).

As to managing changes to AADL_Project: They files are put into plugin_resoruces as read-only. When you try to edit Osate will let you modify if you request it. You can then include the plugin resources in the set of thing you back up into a version control system. When we come out with a new release that includes changes to these property sets, we can provide an update function that updates the plugin_resources by overwriting them. You can then do a merge using whatever merge capability comes with the version control system. It would be nice if Osate could let you know if these property sets have changed as aprt of the new release so you can decide when to upgrade to them.

Peter

From: Jerome Hugues [mailto:notifications@github.com] Sent: Friday, August 10, 2012 12:12 PM To: osate/osate2-core Subject: Re: [osate2-core] Property sets for AADL annexes (#64)

Hi Lutz, Peter,

Do you have any recommendation for this issue, and issue 65? Thanks

— Reply to this email directly or view it on GitHubhttps://github.com/osate/osate2-core/issues/64#issuecomment-7649146.

yoogx commented 12 years ago

IMHO, property sets part of annexes (ARINC653, data, behavior) should be part of OSATE2 distribution, since they can be used in all occasion, even without the corresponding parser for the annex sublanguage implemented.

My rationale is: OSATE2 alone shall process models that are using an annex, it will simply ignore the annex subclause. Yet, it has to parse any additional property sets the annex is using. Since OSATE2 is a reference implementation for the AADL standard collection, it makes sense (at least for me) to have it in the distribution.

I'll comment on AADL_Project in the corresponding ticket for keeping history clear

reteprelief commented 12 years ago

Agreed. I'll add them in as contribution for the next release independent of whether the annex plug-ins are installed.

lwrage commented 12 years ago

I agree for annexes that are just property sets and packages. For the behavior annex and error annex however, wouldn't it be easier to maintain each as a single unit (osate plugin) in the long run? I don't really see a problem if we ask people who want to use just a property set without installing the plugin to download the property set from somewhere and copy it into their workspace.