[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ide-dev] Features discovery
|
On 5 Jan 2016, at 19:32, Mickael Istria wrote:
On 10/19/2015 04:10 PM, Doug Schaefer wrote:
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.
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.
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.
For me both options makes sense.
The p2 metadata requires you to have the p2 update sites registered in
your IDE, correct ? Meaning one could somewhat expect you have a
preference for using the plugins from update sites you already have
configured over something new from marketplace.
And then marketplace entries can be additional suggestions.
Thus the source of these can be used to prioritise them in case there
are multiple candidates.
btw. something I haven't thought about before now - how will this
mechanism handle multiple eclipse versions; you wouldn't expect to
run on Mars and be offered plugins that are from Kepler only. Given any
thought on that ?
/max
http://about.me/maxandersen
