Need for gemoc version specific discovery repositories

[dvojtise]

The current discovery (ie. install additional GEMOC component button) use a single xmi file This does not take into account the fact that the provided components are compatible or not with the studio.

For example, http://kermeta.org/gemoc-ale-execution-engine/updates/2018-06-15/ is compatible with GEMOC studio 3.0.0 but not with 3.1.0

It would be better to have a different discovery catalogue for each version of the studio. So each catalogue would point only to valid update site for the given studio.

the counterparts are:

• we potentially need to duplicate the information.
• how should we manage components that are not compatible anymore? if we simply remove them, a potentially interesting component will not be advertised and we may "forget" about its existence...

[dvojtise]

up, about the question: what should we do with components in the discovery that are not compatible anymore with the current version of the studio ? Should we remove them? (optionally with an issue per invalid component to track the action to reintroduce then when fixed ?)

note: I'm creating subfolders with for the discovery for a given version of GEMOC: the one for the future GEMOC release will be http://gemoc.org/discovery/gemoc_3.1.x/catalog, once GEMOC will be released this summer, a new one will be created: http://gemoc.org/discovery/gemoc_3.2.x/catalog I keep the old http://gemoc.org/discovery/catalog for earlier versions

[ebousse]

Could we display them in gray with a label "Not compatible with the current version"? And disable the installation button? That way they remain visible, but cannot be installed.

[dvojtise]

I don't think this is possible because this comes from amalgam, and this would require to update amalgam

I already tried to submit a request (with the code etc) in order to fix an installation issue using amalgam, and it wasn't processed yet (https://bugs.eclipse.org/bugs/show_bug.cgi?id=531789 February 2018 !) so I'm not very confident in any improvement from amalgam side. Or we have to duplicate code on our side...

Anyway, I think that we should prefer( and encourage) to point to fixed version of update sites. So if a user is using the latest stable GEMOC release, the discovery should point to the latest working version of the tool. While the master could point to a newer version that takes into account GEMOC framework changes.

[dvojtise]

I've verified some of the possibilities of the discovery:

• url not accessible are displayed in grey (a click on it provides a "component foo is unavailable. please try again later) (currently, 2 components are broken this way: bcool operator for tfsm/activity and TESL Engine)
• we can add more information in one of the fields
  • title: we currently already use this to display (Sequential/Concurent) and (Incubation) information
  • short description (may add a short text about supported gemoc versions
  • long description (but this one is visible only when clicking on the :information_source: button)

So I suggest the following:

• use one discovery url per official release (cf. https://github.com/eclipse/gemoc-studio/pull/162) this allows adding/removing components (this was useful for example to introduce the Concurrent MOCCML engine in previous versions but is now useless since it has been added to the studio)
• for every entry: add a note at the end of the short description using a format like [gemoc-studio v3.1.x] indicating clearly the latest version of the studio that has successfully installed and run the component
• if someone finds that a component does not install or run, she can raise an issue, which immediate effect will be to disable the entry by adding an error in the url (for example: add a postfix such as -disabled