Users need a way to override contributed property sets

[lwrage]

Contributed property sets (and packages) used to be copied into the workspace, which we considered bad practice. In #527 we changed that, such that contributed AADL files are read from the contributing plugins. However, now it is impossible to fix errors in such a file without updating OSATE. There should be some way to update just a single contributed file.

We have a specialized mechanism that works for AADL_Project.aadl only.

Who updates the file contents? End user or update mechanism?
What's the scope of the change? Workspace or installation?

[Etienne13]

As mentioned in #1669, solving this issue would help to experiment AADL tools that need to go beyond some limitations in the current version of some property sets (including modeling ARINC653 systems on multicores).

[Etienne13]

I now face this issue again because of the "pok_properties.aadl" file, which is contributed by the osate-ocarina plugin and my own plugin (RAMSES) with two different contents. My current workaround is to uninstall osate-ocarina but is is not satisfactory for my end-users: each time they install RAMSES for a new version of OSATE, they have to uninstall osate-ocarina.

Here is a proposal for this issue: define an order of contributed property sets such that property set N+1 overrides property set N;

• the default order is computed according to the history of installed plugins: the latest is pushed back in the queue and thus overrides the previous ones
• the order can be viewed and changed by end-users

This would be a solution at the installation level which could be changed at the workspace level (or at the project level if needed).

It would not allow to mix (merge/override) property set contents but at least property set files...

[jjhugues]

Pok no longer exists as one os, there are several forks, and I do not have the ressource to maintain thid I can suppress the property set Le 5 juil. 2019 à 12:32, Etienne Borde <notifications@github.com<mailto:notifications@github.com>> a écrit : I now face this issue again because of the "pok_properties.aadl" file, which is contributed by the osate-ocarina plugin and my own plugin (RAMSES) with two different contents. My current workaround is to uninstall osate-ocarina but is is not satisfactory for my end-users: each time they install RAMSES for a new version of OSATE, they have to uninstall osate-ocarina. Here is a proposal for this issue: define an order of contributed property sets such that property set N+1 overrides property set N; * the default order is computed according to the history of installed plugins: the latest is pushed back in the queue and thus overrides the previous ones * the order can be viewed and changed by end-users This would be a solution at the installation level which could be changed at the workspace level (or at the project level if needed). It would not allow to mix (merge/override) property set contents but at least property set files... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#1134?email_source=notifications&email_token=AL7JLSOO555EB7XS7JSA2ALP55ZS7A5CNFSM4E23UR6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZJ5KVA#issuecomment-508810580>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AL7JLSJG2NZ7D7IJW7U3VLTP55ZS7ANCNFSM4E23UR6A>.

[Etienne13]

Hi Jérome,

yes, that would at least solve my problem for now.

Thanks!
Etienne.

[lwrage]

Add workspace scoped preference to configure which contributed AADL is used. Details TBD.

[AaronGreenhouse]

Need more info here.

Processing of contributed AADL files seems to be handled in several places, making this potentially tricky, including:

• org.osate.xtext.aadl2.properties.ui.builder.PropertiesToBeBuiltComputerContribution --- I think this inserts the files into the build process?
• org.osate.xtext.aadl2.ui.containers.Aadl2ProjectsStateHelper --- Not really sure what this does
• org.osate.xtext.aadl2.ui.resource.Aadl2Storage2UriMapper --- Not really sure what this does
• org.osate.ui.navigator.AadlContributionContentProvider --- Adds the contributed files to the AADL navigator tree

Current uses all rely on the method PluginSupportUtil.getContributedAadl(). This method reads all the contributions from the plugin.xml files. If there are duplicates here, then they will simply be propogated. If we want to override a contributed file with a file from the OSATE workspace, then it will be missed here. We would have to replace uses of this method with a new method that returns a manipulated list of contributed files. (This new method would not be applicable to replacing getCongtributedAadlAsClasspath() that is used by stand-alone (non-Eclipse) applications. They would have to there own mechanism for this.)

[AaronGreenhouse]

What is the plan here? I think what is wanted is a way to override a contributed resource with a resource from the workspace, in effect, treating that workspace file as a contributed resource.

I don't think we need to deal with the case of multiple contributed resources with the same name.

So we want an Eclipse workspace preference (and associated UI pane) that allows a file from the workspace to be inserted into the list of contributed resources and possibly replace an existing resource.

Probably better (simpler to think about) is this:

• The preference allows contributed resources to be selected to be ignored (not reported)
• The preference allows files from the workspace to be added to the list of contributed resources.
• The preference panel should not allow the overall list of "contributed resources" - "ignore resources" + "workspace contributions" to contain packages/property sets with duplicate names.

[AaronGreenhouse]

Looked at the special case of AADL_Project.aadl, which can be replaced by an identically named file in the workspace. This works by having the path of the AADL_Project file that should be used saved in a workspace preference. Aadl2ProjectsStateHelper uses the value of this preference instead of the path of any AADL_Project file that is in the contributed resources.

[AaronGreenhouse]

The problem with the current approach (see above) is that the UI doesn't reflect what is happening at all.

I think that ideally in the AADL Navigator, we should have "Plug-in Contributions" and "Workspace Contributions". The first should show anything contributed by a plug-in minus any item that is removed via the workspace preferences. The second show any contributions from the workspace (as set in the preferences).