Community
Participate
Working Groups
Currently you can see that solution provider are creating seperate solutions for different Eclipse releases (just query "indigo" in MPC). The reason I guess is that they want to provide different (excluding) features on different update-sites which is not possible at the current marketplace. The solution-editing must be extended. Proposal: * I can create a new repository which has a 1..n relation to an Eclipse release. * This repository points to a URL and contains several IUs, so that I can setup the following: Solution Plugin A * for Indigo and Helios use http://mydomain/repoA with ius: ** i1 ** i2 ** i3 * for Juno use http://mydomain/repoB with ius: ** i1 ** j2 ** j3 By resolving bug 382134 the server-side does exactly know from which version we're coming and can return in the response the correct update-site and ius.
btw. I wrote https://bugs.eclipse.org/bugs/show_bug.cgi?id=385334#c32 to highlight part of the problems of eclipse marketplace/p2 not being able to handle the major version updates/installs better.
Supporting multiple repositories in one entry might reduce the need for separate entries, but will not eliminate the need. Consider a product that periodically drops support for older Eclipse platform. In this situation, the difference between various product repositories is not just the Eclipse platform that they support, but also the version of the product and by extension its featureset (description). Looking further, an entry also contains installation stats, log of installation failures, etc. All of this information needs to be accessible on per-repository basis. We really need two pieces: 1. MPC to filter search results by Eclipse platform version. 2. A way to group separate entries with each other so that an aggregate view on rating, reviews, stats, etc. can also be provided.
Although I also think it'd be useful to allow multiple versions/sites in a single entry, I don't think it's a good idea to make filtering in MPC. Indeed, choosing between one version or the other is not only choosing a version of the platform, it can be a matter of choosing a version of m2e, or wtp, or any dependency... And I'm doubtful about the idea of defining a kind of rule language to define filters and rules of what can be installed or not... So I'd first go for a 1 entry = N sites asscociation. Each site would have a description, label and so on. From end-user POV using MPC, it would be about finding an entry, independently of the platform version. When the entry is chosen, then user would then be asked to choose a site. This site would appear as a label. For JBoss Tools example, in MarketPlace: 1. We'd have a single JBoss Tools entry 2. It'd list sites for Helios, Indigo, Juno and in MPC a. Users search for JBoss b. When clicking "Install", a new WizardPage (or a combobox or whatever better UI) asks him to choose a site. Sites would have as Label "JBoss Tools 3.2 for Helios", "JBoss Tools 4.0.Alpha1" for Juno... and would also show their description and other data using a master-details principle. c. when site is chosen, then it becomes traditional p2 UI From a provider POV, it would make the project/product less scattered. We can also hope this would provide also some aggregated installation reports. From a consumer POV, it simply looks more straightforward.
Any chance of getting this addressed for Kepler? A simple rule engine based on bundle id and version range should do the trick. The rules can be very simple. A list of bundles with version ranges, similar to an OSGi manifest should work and be rather simple to implement. Then you leave it to the solution provider to decide how specific or not they want the filter to be. Most, I suspect, will just have one rule for one of the platform bundles. The rest of the dependencies can typically be fetched from the EPP repo once you've pinned down the platform version. Adding multiple repositories to the same listing and then asking the user to pick from them via a separate wizard page as outlined in Comment #3 sounds like both more work and less flexible. I know it would not address Oracle's requirements as described. The set of IU's differs from repository to repository and so does the listing description. It would take a large structural change to marketplace schema and UI to pull off removing the need to have multiple listings. It would be great to get filtering as the first step.
It would be great if we could get this addressed for Mars. (In reply to comment #4) > A simple rule engine based on bundle id and version range should do the trick. Are you suggesting to identify if a marketplace entry is compatible with a certain release/client version based on some version range rules? I agree that that would be an important first step, so users don't see incompatible entries. Bug 418864 has been created to discuss that. (In reply to comment #2) > Supporting multiple repositories in one entry might reduce the need for separate > entries, but will not eliminate the need. I think as long as it makes conceptual sense to have only one entry - as is the case for most if not all of the "XXX for Indigo/Juno/Kepler" entries out there - the rest is "just" a releng problem and we should make sure that Marketplace is in line with that - or at least doesn't add unnecessary obstacles. > Consider a product that periodically drops support for older Eclipse platform. > In this situation, the difference between various product repositories is not > just the Eclipse platform that they support, but also the version of the product > and by extension its featureset (description). But is this really needed from the users' point of view? We could of course try to create something that gives solution owners every freedom to structure entries, releases and install artifacts and "express themselves" in any conceivable way. And while as a techie I am prone to designing just that, I don't think that's really desireable here. Instead we should focus first and foremost on what the user expects of the entries in the marketplace. And I think that is first and foremost to have one entry per solution, regardless of available versions or feature set details. Looking at other marketplace systems [1][2][3], they usually have one entry per plug-in/solution/app with a common description, maybe some release notes for the latest version and - if they make different versions available at all - specific version release notes[2]. While our ecosystem here might be a bit more complex with more dependencies and prerequisites all over the place, I don't think we need to reflect that in the user presentation. Also, looking at a number of entries currently on Marketplace that have specific Juno/Kepler/Luna versions, almost all have the exact same description across all versions/entries. So there's a lot of value in consolidating those, even if it doesn't work out in every case. I agree it would be nice to get a few version-specific details, but I think that that could be kept pretty short and light-weight and is a secondary concern. > 2. A way to group separate entries with each other so that an aggregate view on > rating, reviews, stats, etc. can also be provided. This would follow naturally from having just one entry and is what users would expect - i.e. not starting from scratch with installation counts and star ratings for every new release. > Looking further, an entry also contains installation stats, log of installation > failures, etc. All of this information needs to be accessible on per-repository > basis. With installation stats, we have the "marketing numbers", which I think should always be the overall number across repositories anyway. And then there are the technical download counts, which are largely of interest for the solution owner I think. But I think that's a nice-to-have. For more detailed data, it's still possible to run statistics on your update site downloads. Installation failures are much more important to have per repository to identify problems for specific versions or platforms. Getting a qualifier for the repository into the raw data shouldn't be a problem here. I would assume that it's easy to add to the detailed CSV file. I wouldn't break it down on the website, though, for simplicity's sake. > Adding multiple repositories to the same listing and then asking the user to > pick from them via a separate wizard page as outlined in Comment #3 sounds like > both more work and less flexible. I agree that asking the user is not a good idea and adds unnecessary complexity. I think we should have the possibility for multiple repositories with their own IUs, as suggested in the original post. But the choice between them should be made automatically based on the client's eclipse version. Each repository and corresponding IU list should be tied to an Eclipse platform version range as suggested for the whole entry in bug 418864. Then the server can choose, based on the information provided by the requesting MPC client, which repository/ius to return in its reply. I would not allow the solution provider to specify free-form OSGi version ranges though, because a) that'll probably complicate the filtering logic on the server and b) it'll significantly increase the risk of "bad" ranges (e.g. malformed, or excessively wide and open to future Eclipse versions that can't possibly be checked at the time). > It would be great to get filtering as the first step. Agreed on filtering entries based on compatibility as a first step, see bug 418864. -- [1] https://play.google.com/store/apps [2] https://addons.mozilla.org [3] https://itunes.apple.com/us/app/whattobdone/id567413558?mt=8
This task has been completed and we are now filtering out incompatible marketplace listings.
