| [ide-dev] Features discovery |
|
On 10/19/2015 04:10 PM, Doug Schaefer
wrote:
I'm currently working on this topic, and with Neon nightly (including fix for https://bugs.eclipse.org/bugs/show_bug.cgi?id=90292 ) + https://github.com/jbosstools/jbosstools-playground/blob/suggestInstallationForUnknownTypes/plugins/org.jboss.tools.playground.refreshment/src/org/jboss/tools/playground/refreshment/editorRegistry.json , I have the IDE suggesting me to install new content when I hit a file that have no editor associated. That helped me to get a stronger opinion on the question of how to recommend installation to users.Even better, add the supported file types as a provided capability in the p2 metadata just like we do with Java packages now. That¹s something we could easily do now with no code required by the provider other than the p2.inf file. And on the consumer side, it should be easy to install with the capability as a dependency. Basically, the issue will be on how much choice we want to give to users, or more how much choice users want; and if they have choice, what do we provide them as guidance? If using p2 metadata only, it's much too weak for users to make a good choice. Moreover, p2 metadata would most likely be on the plugin that provide the editor whereas we would often prefer users to install the features. Marketplace provide some nice metadata that help users in making a choice: the full featured description, last update, compatibility with Eclipse versions, comments, and even more important in that case, stars. Users need those metadata, so IMO, Marketplace is by far the best place to store filetype->features association. The discovery that I currently drafted as a JSON file using p2 installer could be a remote service on marketplace that would return one or several MarketPlace entries for the given file; and allow user to choose one or several of them via Marketplace Client. Cheers, |