Community
Participate
Working Groups
This is a container bug to help me plan a solution to resolve Bug 304949 - determine how we should handle solutions that don't apply to the client os/platform/Eclipse version etc. Here's my plan: 1 - Understand who's currently using MPC: Bug #418855 - Create a usage report with the data that MPC is currently sending back to us 2.1 We need to discuss how we should manage different repo for different eclipse version on the marketplace website: Bug #385883 - Different repositories for different Eclipse versions 2.2 How should we manage compatibility Bug #418864 - Discuss how we should be managing compatibility on marketplace 3 - Once we are done with #418855, #385883 and #418864, we will need to create a new bug for each of the following items: 3.1 - How should we communicate with solution providers and remind them to update their listing for an upcoming release. 3.2 - Update marketplace solution form to include fields for storing compatibility information. 3.3 - Allow MPC users to by-pass the incompatible software filter and allow them to search/browse the full set of marketplace solutions. 3.3. Creating and defining a test plan
Ian asked me to give you some input on this based on our own experience with the marketplace and what we learned from other marketplace users we talked to. First of all, a lot of people did complain about this both from the solution owner's and from the user perspective. As a solution owner, they have to maintain separate entries with a lot of redundant information to target different Eclipse versions. As a user, they get quite some obviously incompatible entries in the MPC client (xxx for Helios) and worse, some that just won't work with the current release. That said, I think it would be a good idea to tackle 2.2 first, and then look into 2.1, because a) it goes a long way toward fixing the problem for the users and b) the version information from 2.2 will be needed for 2.1. I'll comment with details on the subtasks #418864 and #385883. I'll include some thoughts on 3.1-3.3 there as well.
Regarding testing, I can offer to add tests to the MPC test suite that check for filtering of incompatible entries, as well as for the right repositories wrt bug 385883
Chris, based on the test reports at https://hudson.eclipse.org/mpc/job/epp-mpc-rest-tests/lastCompletedBuild/testReport/, I see a few remaining issues: 1) I can create entries where no "Supported platform" is selected. I think that's fine, but in that case, it should be treated as compatible with all OS platforms. Instead it seems that it's incompatible to all: https://marketplace-staging.eclipse.org/content/test-entry-kepler https://hudson.eclipse.org/mpc/job/epp-mpc-rest-tests/lastCompletedBuild/testReport/org.eclipse.epp.mpc.tests.service/SolutionCompatibilityFilterTest/testCompatibleInstallableNode_10__KEPLER__with__KEPLER_WIN32_/ 2) When no eclipse version information is available to determine compatibility, I think we should treat everything as compatible as well - to be on the safe side with odd clients, firewalls and such... See https://hudson.eclipse.org/mpc/job/epp-mpc-rest-tests/lastCompletedBuild/testReport/org.eclipse.epp.mpc.tests.service/SolutionCompatibilityFilterTest/testCompatibleInstallableNode_9__KEPLER__with__UNKNOWN_WIN32_/ 3) Support of legacy MPCs pre-Kepler: I forgot about this completely. MPC versions for Juno and earlier didn't send the platform.version parameter, just the runtime.version. So if platform.version isn't present, you'll need to fall back to the value of runtime.version (see also pt.5): https://hudson.eclipse.org/mpc/job/epp-mpc-rest-tests/lastCompletedBuild/testReport/org.eclipse.epp.mpc.tests.service/SolutionCompatibilityFilterTest/testCompatibleInstallableNode_25__JUNO_AND_EARLIER__with__JUNO_WIN32_/ https://hudson.eclipse.org/mpc/job/epp-mpc-rest-tests/lastCompletedBuild/testReport/org.eclipse.epp.mpc.tests.service/SolutionCompatibilityFilterTest/testCompatibleInstallableNode_22__JUNO_AND_EARLIER__with__INDIGO_WIN32_/ 4) Eclipse 3.8 somehow isn't matched properly, not even if platform.version is present - and not against "Juno" or "Previous to Juno": https://marketplace-staging.eclipse.org/content/test-entry-juno-and-earlier https://hudson.eclipse.org/mpc/job/epp-mpc-rest-tests/lastCompletedBuild/testReport/org.eclipse.epp.mpc.tests.service/SolutionCompatibilityFilterTest/testCompatibleInstallableNode_24__JUNO_AND_EARLIER__with__JUNO_3_8_WITH_PLATFORM_WIN32_/ 5) Speaking of 3.8, that one is a bit special, because it was the twin release to the official Juno 4.2. Most stuff compatible with Juno will also be compatible with 3.8 - unless it uses the new e4 apis directly, which was rare at the time. So we should either treat Juno as "4.2 or 3.8", or add an additional "3.8" version. Since you won't be able to discern between 4.2 and 3.8 versions without platform.version (because they have the same runtime.version value - see pt.3), it probably makes sense to do the "4.2 or 3.8" option. https://hudson.eclipse.org/mpc/job/epp-mpc-rest-tests/lastCompletedBuild/testReport/org.eclipse.epp.mpc.tests.service/SolutionCompatibilityFilterTest/testCompatibleInstallableNode_3__JUNO__with__JUNO_3_8_WITH_PLATFORM_WIN32_/ https://hudson.eclipse.org/mpc/job/epp-mpc-rest-tests/lastCompletedBuild/testReport/org.eclipse.epp.mpc.tests.service/SolutionCompatibilityFilterTest/testCompatibleInstallableNode_2__JUNO__with__JUNO_3_8_WIN32_/ 6) Handling conflicts: When multiple solution versions are applicable, we should probably choose the one that supports the newer Eclipse releases. If that's not enough of a tie-breaker, I'd pick the one further down in the list (i.e. the "newer one"). I wouldn't want to get into parsing and comparing the version number field, because that way lies certain madness with all the version schemes and free-text marketing versions floating around... https://hudson.eclipse.org/mpc/job/epp-mpc-rest-tests/lastCompletedBuild/testReport/org.eclipse.epp.mpc.tests.service/SolutionCompatibilityFilterTest/testCompatibleInstallableNode_77__CONFLICT__with__LUNA_WIN32_/ 7) Non-installable entries: With the current UI, I wasn't able to create an entry without the installable bits (e.g. for an RCP product that's not installable, but just has a zip download). The last remaining solution version cannot be deleted (same for the feature - but that makes sense) and I can't submit with everything left empty in the solution version.
(In reply to Carsten Reckord from comment #3) > Chris, based on the test reports at > https://hudson.eclipse.org/mpc/job/epp-mpc-rest-tests/lastCompletedBuild/ > testReport/, I see a few remaining issues: I seem to be passing all the tests now :) https://hudson.eclipse.org/mpc/job/epp-mpc-rest-tests/25/ > > 1) I can create entries where no "Supported platform" is selected. I think > that's fine, but in that case, it should be treated as compatible with all > OS platforms. Instead it seems that it's incompatible to all: > https://marketplace-staging.eclipse.org/content/test-entry-kepler > https://hudson.eclipse.org/mpc/job/epp-mpc-rest-tests/lastCompletedBuild/ > testReport/org.eclipse.epp.mpc.tests.service/SolutionCompatibilityFilterTest/ > testCompatibleInstallableNode_10__KEPLER__with__KEPLER_WIN32_/ I added a new exception: if "Supported platform" is empty, all platform will be supported. > > 2) When no eclipse version information is available to determine > compatibility, I think we should treat everything as compatible as well - to > be on the safe side with odd clients, firewalls and such... See > https://hudson.eclipse.org/mpc/job/epp-mpc-rest-tests/lastCompletedBuild/ > testReport/org.eclipse.epp.mpc.tests.service/SolutionCompatibilityFilterTest/ > testCompatibleInstallableNode_9__KEPLER__with__UNKNOWN_WIN32_/ This is what I am doing now: I will return the first compatible "installation profile" found if a valid OS and valid Eclipse version is set. If only a valid OS is set, I will return the first compatible version. I have a question now: What should we do if we don't have a valid os or a valid eclipse version? Right now, I am not retuning any installation information: http://marketplace-staging.eclipse.org/content/test-entry-juno/api/p?os=win32&client=org.eclipse.epp.mpc.core&java.version=1.7.0_75&ws=win32&nl=en_US http://marketplace-staging.eclipse.org/content/test-entry-juno/api/p > > 3) Support of legacy MPCs pre-Kepler: I forgot about this completely. MPC > versions for Juno and earlier didn't send the platform.version parameter, > just the runtime.version. So if platform.version isn't present, you'll need > to fall back to the value of runtime.version (see also pt.5): > https://hudson.eclipse.org/mpc/job/epp-mpc-rest-tests/lastCompletedBuild/ > testReport/org.eclipse.epp.mpc.tests.service/SolutionCompatibilityFilterTest/ > testCompatibleInstallableNode_25__JUNO_AND_EARLIER__with__JUNO_WIN32_/ > https://hudson.eclipse.org/mpc/job/epp-mpc-rest-tests/lastCompletedBuild/ > testReport/org.eclipse.epp.mpc.tests.service/SolutionCompatibilityFilterTest/ > testCompatibleInstallableNode_22__JUNO_AND_EARLIER__with__INDIGO_WIN32_/ Here's what I am doing now: 1. I am setting my platform_version variable in my code to the value of product.version GET parameter. 2. I overwrite the platform_version variable if the platform.version GET parameter is set. 3. Then I verify if the value of my plateform_version variable is a valid Eclipse Version. If not, I am ignoring the eclipse version when choosing the proper installation information to return to the client. I am currently not doing anything with the runtime.version. Is there a way to match up the runtime version with an Eclipse version, maybe with some kind of mapping table? > > 4) Eclipse 3.8 somehow isn't matched properly, not even if platform.version > is present - and not against "Juno" or "Previous to Juno": > https://marketplace-staging.eclipse.org/content/test-entry-juno-and-earlier > https://hudson.eclipse.org/mpc/job/epp-mpc-rest-tests/lastCompletedBuild/ > testReport/org.eclipse.epp.mpc.tests.service/SolutionCompatibilityFilterTest/ > testCompatibleInstallableNode_24__JUNO_AND_EARLIER__with__JUNO_3_8_WITH_PLATF > ORM_WIN32_/ You are right, I forgot about 3.8. > > 5) Speaking of 3.8, that one is a bit special, because it was the twin > release to the official Juno 4.2. Most stuff compatible with Juno will also > be compatible with 3.8 - unless it uses the new e4 apis directly, which was > rare at the time. So we should either treat Juno as "4.2 or 3.8", or add an > additional "3.8" version. Since you won't be able to discern between 4.2 and > 3.8 versions without platform.version (because they have the same > runtime.version value - see pt.3), it probably makes sense to do the "4.2 or > 3.8" option. > https://hudson.eclipse.org/mpc/job/epp-mpc-rest-tests/lastCompletedBuild/ > testReport/org.eclipse.epp.mpc.tests.service/SolutionCompatibilityFilterTest/ > testCompatibleInstallableNode_3__JUNO__with__JUNO_3_8_WITH_PLATFORM_WIN32_/ > https://hudson.eclipse.org/mpc/job/epp-mpc-rest-tests/lastCompletedBuild/ > testReport/org.eclipse.epp.mpc.tests.service/SolutionCompatibilityFilterTest/ > testCompatibleInstallableNode_2__JUNO__with__JUNO_3_8_WIN32_/ I am now setting my platform_version variable to 4.2 if the platform.version/product.version get parameter is set to 3.8. > > 6) Handling conflicts: When multiple solution versions are applicable, we > should probably choose the one that supports the newer Eclipse releases. If > that's not enough of a tie-breaker, I'd pick the one further down in the > list (i.e. the "newer one"). I wouldn't want to get into parsing and > comparing the version number field, because that way lies certain madness > with all the version schemes and free-text marketing versions floating > around... > https://hudson.eclipse.org/mpc/job/epp-mpc-rest-tests/lastCompletedBuild/ > testReport/org.eclipse.epp.mpc.tests.service/SolutionCompatibilityFilterTest/ > testCompatibleInstallableNode_77__CONFLICT__with__LUNA_WIN32_/ I am sorting all the installation information based off the Eclipse version. If there is a conflict, I will return the installation information with the latest eclipse version. Right now, it's possible for me to return installation information for Mars first. Should we consider returning the installation information for the current release first? For example: 1.Luna 2.Mars 3.Kepler... > > 7) Non-installable entries: With the current UI, I wasn't able to create an > entry without the installable bits (e.g. for an RCP product that's not > installable, but just has a zip download). The last remaining solution > version cannot be deleted (same for the feature - but that makes sense) and > I can't submit with everything left empty in the solution version. I still need to work on the UI to fix some of these issues.
This task has been completed and we are now filtering out incompatible marketplace listings.
