Management of AADL_Project

[yoogx]

Hi,

Let us suppose you have an AADL project hosted in a SCM, and that you need to update AADL_Project. What is the best way to manage modifications in this file without creating conflicts with the files in Plug-in Ressources?

thanks

[yoogx]

Peter, in issue #64, you wrote:

"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."

Your proposal should work for me, but where is stored (in Eclipse resource wording) plug-in resources? for instance: what would happen ifI ask OSATE2 to create again plug-in resources? what if I have multiple projects, with different variants of AADL_Project? I did not test whether this could create a problem, I'm just trying to imagine what a user could do.

Actually, my expectation would be that when you create an AADL project with the AADL wizard, a fresh copy of AADL_Project.aadl is put in the user workspace. I do not want OSATE to let me modify anything in plug-in resources, as it would create discrepancies: standard property sets should not be modifiable

[lwrage]

Allowing modification of AADL_Project supports a use case like the following: Assume you write an OSATE plugin that processes a new scheduling protocol. You then need to add a new entry to the enumeration Supported_Scheduling_Protocols in AADL_Project. (Supported_Scheduling_Protocols: type enumeration (FixedTimeline, Cooperative, RMS, EDF, SporadicServer, SlackServer, ARINC653, );).

However, I don't know if anyone has ever done this with OSATE.

Ideally we wouldn't even copy the property sets into the workspace but only show them unmodifiable virtual resources in the AADL navigator. OSATE1 used to work like that.

[yoogx]

Well, I'm currently doing it (or would like to) in another project (just browse my list of projects, the one called AADLib). It aims at defining a library of models that works both with OSATE2 and Ocarina. Since we have mapping for Cheddar and MAST (see osate2-ocarina project, it brings ocarina transformations to OSATE2), I need what you describe: extending AADL_Project. I could do it locally, but I'd prefer see what is the recommended practice.

[lwrage]

Currently we have no mechanism implemented that allows shadowing/overriding - whatever you want to call it - of a predefined property set or any other property set or package. In OSATE1 we tried to implement such a general mechanism but that was too buggy to be useful. With XText it seems to be possible to implement this using project dependencies which can define a search path for property sets and packages. That would also allow several variants of AADL_Project. Maybe we can figure out how to do that, but it seems to be fairly complicated in detail and a lot of work.

[juli1]

Dear all,

This bug is quite old and there are several solutions to address it :

1. We can leave it open until we foresee a solution
2. We can also include other definitions required by user in our AADL_Project.aadl (after all, if this is really needed, by our user, we should include additional values)
3. Jerome already find a solution by its own and there is no need to address this.

Please let us know which option sounds the most reasonable for you.

[yoogx]

Le 24 déc. 2012 à 15:50, Julien notifications@github.com a écrit :

Dear all,

This bug is quite old and there are several solutions to address it :

1. We can leave it open until we foresee a solution
2. We can also include other definitions required by user in our AADL_Project.aadl (after all, if this is really needed, by our user, we should include additional values)
3. Jerome already find a solution by its own and there is no need to address this.

Please let us know which option sounds the most reasonable for you.

I prefer option 1. As of today, we need a clear procedure for end users to manage AADL_Project on a per project basic I have a work-around for 3., but it is not sustainable on the long term

This is something we will have to discuss with Pierre, as it is an issue for tool interoperability and project management.

Regards,

[juli1]

What has been implemented for 3 ? Also, if a discussion is being started, this shared collaborative place could be used, feel free to invite anybody to join.

[yoogx]

Le 24 déc. 2012 à 18:55, Julien notifications@github.com a écrit :

What has been implemented for 3 ? Also, if a discussion is being started, this shared collaborative place could be used, feel free to invite anybody to join.

1. is a local modification on my workspace, and the workspace of the intern working with OSATE2. This is not satisfactory as the modification must be manually copied on all computers

[juli1]

One workaround would be the following :

1. You add all the property set from your project in the workspace
2. You remove the reference to the ResourcesPlugin by editing the Project Reference in the plugin properties

In that case, OSATE does not process its own property files and use the one from our project.

Does that adress your issue or do you think another mechanism would be necessary ?

[yoogx]

Having all property sets is an overkill. We really need to have just AADL_Project. To me OSATE2 workflow should be

• use AADL wizard to create a project, and place a regular copy of AADL_Project in the root
• remove AADL_Project from resourcesplugin
• have an option to recreate AADL_Project in case the user delete it

Of course, if this cannot be supported, I'll do the way you suggest.

[juli1]

Ok, what about the two following scenario :

• If there is a AADL_Project.aadl file in the project root, we use this one instead of the one in the predeclared properties
• We have a project preference to indicate the location of a Project File

What do you think about these alternatives ?

[yoogx]

Having a project preference to indicate the location of AADL Project got my vote. As it is explicit to the end user.

[juli1]

Hi Jerome,

First part of the job is done. I added a special preferences page in OSATE. Plese right-click on your project, you can select which AADL file to use within your project as a AADL_Project.aadl file.

Please let me know if this is ok for you. If appropriate, we will use the file in the parser to use user-specified properties.

Thanks for your feedback.

[yoogx]

Hi,

I just tested this feature using last night snapshot. I can copy/paste the location of an AADL_Project file, it would be even better to have a browse button attached.

[juli1]

Hi,

I integrated most of the properties you use in AADLlib. Please send pull request when you need other properties. We leave it open in case we have some mechanisms to handle user-defined AADL_Project.aadl files.

[juli1]

Follow-up on this topic. Can you tell us if the changes fit with your needs ? I also add a description in the OSATE help for using your own property set, please tell me if that sounds clear for you.

[yoogx]

The documentation is clear. I'll do a pull request for missing enumerators if required. Thanks

[juli1]

Re-opening of the issue. We have several requests to implement such a mechanism.

[lwrage]

Xtext supports a classpath mechanism to look up files. To use the default implementation each project must have the java nature. Then remove the project dependencies and add .classpath files to the project. This works as expected. To make this usable there's some customization required:

• Simplify file format - ordered list of project names
• Provide an editor for dependencies in the project properties - select projects, ordering
• Implement Xtext container handling - process project list, use all aadl files in projects
• Modify checking for duplicate packages/property sets
• Modify AADL project wizard - set initial search path instead of project dependencies
• Make Plugin_Resources a virtual project

[lwrage]

Default implementation classes are in package org.eclipse.xtext.ui.containers.

[lwrage]

The classpath mechanism is not helping, too much configuration needed. From a user perspective the solution should look like the following

• There is one active AADL_Project property set per workspace
• The file name must be AADL_Project.aadl
• The active one can be in any project
• The user can right click on one of these files to make it active
• The navigator highlights the active one, others are greyed out
• The active AADL_Project file is stored as a preference
• Context menu action on active one to revert to the standard version
• If the project containing the active one is closed, the user needs to select another one
• Automatic workspace build is triggered by change in active file