Community
Participate
Working Groups
Similar to Bug 509929, I suggest to remove the "dead" marketplace entries.
I noticed that this ones seemed "dead": https://marketplace.eclipse.org/content/eclipse-notepad-plugin Though I suspect there will be a better automated way to find all of them.
So I have the testing working again, but I realize now that when I query a category, I only get the first 10 nodes at most: https://marketplace.eclipse.org/taxonomy/term/4,31/api/p https://wiki.eclipse.org/Marketplace/REST#Retrieving_a_set_of_listings_from_a_specific_Market_.2F_Category Nothing spelled out in the REST API how I can gather a list of all nodes that I could test. What I need is the set of all nodes. without that I cannot help with testing.
We are currently planning to release a new version of our API by the end of the quarter. This new API will have new features that the old one does not have such as pagination. I would recommend that we postpone this exercise until the new API is live. Implementation: https://github.com/EclipseFdn/marketplace-rest-api Documentation: https://eclipsefdn.github.io/marketplace-rest-api-specs/
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=552245 for updated details on the progress of what I demoed at EclipseCon....
Now that we have a full report: https://www.eclipse.org/setups/marketplace/?style=error The question is how best to remove completely bogus listings? All the listings with an error marker cannot be installed in any version of Eclipse. All the ones with a warning marker need to restrict the range of versions in which they claim to be installable.
(In reply to Ed Merks from comment #5) > Now that we have a full report: > > https://www.eclipse.org/setups/marketplace/?style=error > > The question is how best to remove completely bogus listings? > > All the listings with an error marker cannot be installed in any version of > Eclipse. > > All the ones with a warning marker need to restrict the range of versions in > which they claim to be installable. Good to have a report! I would suggest sending a mail round to all plugin developers concerned and then either automatically remove the solution or restrict the available versions if no action is taken after a month or so. By the way, how often is the report updated? I did fix one of my solutions a couple of days ago, but it still shows up in the report.
(In reply to Pierre-Yves B. from comment #6) > Good to have a report! I would suggest sending a mail round to all plugin > developers concerned and then either automatically remove the solution or > restrict the available versions if no action is taken after a month or so. > Yes, making the listing providers aware would be a good first step. > By the way, how often is the report updated? I did fix one of my solutions a > couple of days ago, but it still shows up in the report. I was only running it manually and that's been almost two weeks ago: https://ci.eclipse.org/oomph/job/marketplace-analyzer/ I've changed to it run daily and kicked off a manual build as well. It takes about 45 minutes to complete. Unfortunately our build instance has only two executors but the build instance is used for a number of very time consuming "general Eclipse infrastructure reports". In fact most of our executor processing is spent on general things and this is starting to become a problem...
Created attachment 280694 [details] Odd hyperlinks By the way, I noticed that the hyperlinks looked a bit odd in the report.
(In reply to Ed Merks from comment #7) > I've changed to it run daily and kicked off a manual build as well. It takes > about 45 minutes to complete. > > Unfortunately our build instance has only two executors but the build > instance is used for a number of very time consuming "general Eclipse > infrastructure reports". In fact most of our executor processing is spent > on general things and this is starting to become a problem... If executor capacity is an issue, maybe a weekly report is enough? That could simply be mentioned in the reports page just so that people are aware that the data may be slightly outdated.
(In reply to Pierre-Yves B. from comment #8) > Created attachment 280694 [details] > Odd hyperlinks > > By the way, I noticed that the hyperlinks looked a bit odd in the report. The hyper link is only underlined when it is the current selected item, i.e., after you click on it and come back to the original page. It also underlines when you hover over it. I suppose there would be some style one could use to turn off the "active selection" underlining that it seems unproblematic to me...
(In reply to Ed Merks from comment #5) > Now that we have a full report: > > https://www.eclipse.org/setups/marketplace/?style=error > > The question is how best to remove completely bogus listings? Thanks a bunch Ed for this works. I think I fixed WindowBuilder and Dartboard. Is their a way how I can re-run the validation?
(In reply to Lars Vogel from comment #11) > (In reply to Ed Merks from comment #5) > > Now that we have a full report: > > > > https://www.eclipse.org/setups/marketplace/?style=error > > > > The question is how best to remove completely bogus listings? > > > Thanks a bunch Ed for this works. I think I fixed WindowBuilder and > Dartboard. Is their a way how I can re-run the validation? I rebuilt, but looking in the cache of the build job: https://ci.eclipse.org/oomph/job/marketplace-analyzer/ws/report/home/.eclipse/org.eclipse.oomph.setup/cache/https___marketplace.eclipse.org_content_windowbuilder_api_p_platform.version=4.10/*view*/ That looks older than what I see actually returned from: https://marketplace.eclipse.org/content/windowbuilder/api/p?platform.version=4.10 But I wipe out the workspace before building, so I don't know why the stale content is found/used. I'll need to investigate... And I can't do new builds to actually change any code because I'm blocked by this right now: https://bugs.eclipse.org/bugs/show_bug.cgi?id=553205
I manually wiped out the workspace and now this looks new (without the bogus css iu): https://ci.eclipse.org/oomph/job/marketplace-analyzer/ws/report/home/.eclipse/org.eclipse.oomph.setup/cache/https___marketplace.eclipse.org_content_windowbuilder_api_p_platform.version=4.10/*view*/ So hopefully results will be properly updated in the next hour.
The results appear properly updated now with WindowBuilder free of errors.
I am little bit confused why https://www.eclipse.org/setups/marketplace/?style=error lists some of my plugins - e.g. "Bash Editor" and "SQL Editor" The are listed to have errors when using - neon - oxygen Error is always osgi.ee dependency: - Missing requirement: SQL Editor 1.0.0 (de.jcup.sqleditor 1.0.0) requires 'osgi.ee; (&(osgi.ee=JavaSE)(version=1.8))' but it could not be found But no errors when eclipse versions are equal or higher than - photon - 2019-xx Looking at https://github.com/de-jcup/eclipse-bash-editor/blob/master/basheditor-plugin/META-INF/MANIFEST.MF or https://github.com/de-jcup/eclipse-sql-editor/blob/master/sqleditor-plugin/META-INF/MANIFEST.MF I see no dependency to any osgi.ee part. Also the SQL Editor 1.0.0 does work with the newer eclipse runtimes without any problems . An other plugin "Batch Editor" is not listed to have any problems, but MANIFEST looks nearly same: https://github.com/de-jcup/eclipse-batch-editor/blob/master/batcheditor-plugin/META-INF/MANIFEST.MF So my two questions are: - where comes the dependency to osgi.ee ? I have declared none. - what are solution owners supposed to do? (I would like to support older eclipse versions as long as possible as long as there is no real API conflict)
(In reply to Albert Tregnaghi from comment #15) > I am little bit confused why > https://www.eclipse.org/setups/marketplace/?style=error > > lists some of my plugins - e.g. "Bash Editor" and "SQL Editor" > > The are listed to have errors when using > - neon > - oxygen > > Error is always osgi.ee dependency: > - Missing requirement: SQL Editor 1.0.0 (de.jcup.sqleditor 1.0.0) requires > 'osgi.ee; (&(osgi.ee=JavaSE)(version=1.8))' but it could not be found > > But no errors when eclipse versions are equal or higher than > - photon > - 2019-xx P2 in Photon gained support for capabilities and represents BREE (deprecated in OSGi) as osgi.ee. This probably means that the report is using photon or newer p2 to resolve for old versions thus the failures in the report aka false positives. > > Looking at > https://github.com/de-jcup/eclipse-bash-editor/blob/master/basheditor-plugin/ > META-INF/MANIFEST.MF > or > https://github.com/de-jcup/eclipse-sql-editor/blob/master/sqleditor-plugin/ > META-INF/MANIFEST.MF > > I see no dependency to any osgi.ee part. > > Also the SQL Editor 1.0.0 does work with the newer eclipse runtimes without > any problems . > > An other plugin "Batch Editor" is not listed to have any problems, but > MANIFEST looks nearly same: > https://github.com/de-jcup/eclipse-batch-editor/blob/master/batcheditor- > plugin/META-INF/MANIFEST.MF > > So my two questions are: > - where comes the dependency to osgi.ee ? I have declared none. > - what are solution owners supposed to do? > (I would like to support older eclipse versions as long as possible as long > as there is no real API conflict)
(In reply to Alexander Kurtakov from comment #16) >... > P2 in Photon gained support for capabilities and represents BREE (deprecated > in OSGi) as osgi.ee. This probably means that the report is using photon or > newer p2 to resolve for old versions thus the failures in the report aka > false positives. > ... Thank you for your answer, Alexander. So I will just ignore / accept these results as false positives.
It would be nice if Ed can try generating the report with old p2 so we are sure this is the case.
(In reply to Alexander Kurtakov from comment #18) > It would be nice if Ed can try generating the report with old p2 so we are > sure this is the case. It's not so easy to provide builds against older target platforms... I ran into a similar problem with a listing that had a Java 13 BREE; older p2 update sites did not include the osgi.ee for that... Another possible approach/solution to address this is if I had a p2 repository with all these osgi.ee IUs so that nothing would ever fail purely because of a missing BREE requirement. I was also looking at whether the report could include the BREE requirement(s) of the IUs being installed, but older IUs don't include there BREE information in the metadata so I could only determine that in general by downloading all the artifacts and looking at the MANIFEST.MF, which would make testing much, much slower...
Albert, Thanks for reviewing the quality of your listing! I've upgraded the report generator so that it uses an additional repository that contains just the newest version of a.jre.javase from among all the release train repositories while resolving the listing's requirements. This is the IU that contains the problematic osgi.ee capabilities. With that in place both these listings are error free: https://www.eclipse.org/setups/marketplace/?url=https://marketplace.eclipse.org/content/bash-editor https://www.eclipse.org/setups/marketplace/?url=https://marketplace.eclipse.org/content/sql-editor In fact it appears as if both these listings would install in Eclipse versions not declared in the listing itself: https://marketplace.eclipse.org/content/sql-editor/api/p I.e., it appears they would install as far back as Juno/4.2. Overall there are 33 fewer listings with reported problems using this approach.
Note that I've also added testing against 2019-12/4.14.
The analyzer is currently producing false positives. E.g., when testing https://marketplace.eclipse.org/content/eclipse-xtext against Juno this p2 task is used to test the resolution. <?xml version="1.0" encoding="UTF-8"?> <setup.p2:P2Task xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:setup="http://www.eclipse.org/oomph/setup/1.0" xmlns:setup.p2="http://www.eclipse.org/oomph/setup/p2/1.0" label="Eclipse Platform (Juno) + Eclipse Xtext" licenseConfirmationDisabled="true"> <requirement name="org.eclipse.platform.feature.group"/> <requirement name="org.eclipse.xtext.sdk.feature.group"> <annotation source="Data"> <detail key="name"> <value>Xtext Complete SDK</value> </detail> </annotation> </requirement> <requirement name="org.eclipse.platform.ide" versionRange="[4.2.0,5.0.0)"/> <requirement name="org.eclipse.platform.feature.group" versionRange="[4.2.0,5.0.0)"/> <requirement name="org.eclipse.rcp.feature.group" versionRange="[4.2.0,5.0.0)"/> <requirement name="org.eclipse.oomph.setup.feature.group"/> <repository url="http://download.eclipse.org/modeling/tmf/xtext/updates/releases/2.20.0"/> <repository url="file:/D:/marketplace-report-test-new/jre"/> <repository url="http://download.eclipse.org/releases/juno/201303010900"> <annotation source="http://www.eclipse.org/oomph/setup/ReleaseTrain"/> </repository> <repository url="http://download.eclipse.org/modeling/emf/emf/builds/release/2.20"/> <repository url="http://download.eclipse.org/oomph/updates/milestone/latest"/> </setup.p2:P2Task> This resolves, but not for the expected reason. In particular, org.eclipse.xtext.sdk.feature.group resolves to the version in http://download.eclipse.org/releases/juno/201303010900 not to the version in http://download.eclipse.org/modeling/tmf/xtext/updates/releases/2.20.0 as we really should be testing. Because when one does "install new software" in the IDE, p2 effectively tries to install exactly the version in the specified repository not just any version visible in any available/enabled repository. So the testing will currently produce false positives for any listing that specifies IUs available in the train repo itself. I'll need to either verify the resolved version of the list's IUs or probably better restrict the p2 tasks requirement to exactly the version from the list's repo.
I added a version range to the listing requirements so that we test that the actual version in the listing's update site must be resolved in order for the test to pass. For this specific listing we can now see that it will only install in 2019-12: https://www.eclipse.org/setups/marketplace/?url=https://marketplace.eclipse.org/content/eclipse-xtext When I tried manually to install in Juno, it failed because it couldn't resolve against the Eclipse Platform IUs, e.g., org.eclipse.help 3.8.1 could not be resolved. When I tried manually to install in 2019-09, it went into remediation mode and offered to install Xtext 2.19 instead of Xtext 2.20. The failure in this case of the tests is: Missing requirement: Xtext Complete SDK 2.20.0.v20191202-1256 (org.eclipse.xtext.sdk.feature.group 2.20.0.v20191202-1256) requires 'org.eclipse.equinox.p2.iu; org.eclipse.emf.mwe2.language.sdk.feature.group 2.11.1' but it could not be found So I think this problem could be addressed by referencing a composite that includes the MWE2's 2.11.1 update site and the Xtext 2.20.0 update site.
Java 13 Support (https://marketplace.eclipse.org/content/java-13-support-eclipse-2019-09-413) is marked red but it works/installs just fine. The entry clearly says it needs to be installed on top of Eclipse IDE. The exception stack trace itself mainly has oomph in the entries. So, looks like the test does not just install Eclipse IDE (which of course the test cannot know) and then the Java support. If that can't be fixed then there must be a way for MPE providers to remove that health status icon.
(In reply to Dani Megert from comment #24) > Java 13 Support > (https://marketplace.eclipse.org/content/java-13-support-eclipse-2019-09- > 413) is marked red but it works/installs just fine. The entry clearly says > it needs to be installed on top of Eclipse IDE. The exception stack trace > itself mainly has oomph in the entries. So, looks like the test does not > just install Eclipse IDE (which of course the test cannot know) and then the > Java support. If that can't be fixed then there must be a way for MPE > providers to remove that health status icon. I'll investigate when I'm back next week. The important information is the p2 failure message: - Missing requirement: Eclipse JDT (Java Development Tools) Patch with Java 13 support for 2019-09 development stream 1.1.1.v20190918-0918_BETA_JAVA13 (org.eclipse.jdt.java13patch.feature.group 1.1.1.v20190918-0918_BETA_JAVA13) requires 'org.eclipse.equinox.p2.iu; org.eclipse.jdt.feature.group [3.18.100.v20190916-1045,3.19.0.v20201201-1800)' but it could not be found - Cannot satisfy dependency: - From: artificial_root 1.0.0.v1576032676614 - To: org.eclipse.equinox.p2.iu; org.eclipse.jdt.java13patch.feature.group [1.1.1.v20190918-0918_BETA_JAVA13,1.1.1.v20190918-0918_BETA_JAVA13] And the question is, is this IU version range visible in the release train repository? org.eclipse.jdt.feature.group [3.18.100.v20190916-1045,3.19.0.v20201201-1800) I'll check but if p2 doesn't find it it mustn't be there... I can use the repository explorer to find where it is...
(In reply to Dani Megert from comment #24) > Java 13 Support > (https://marketplace.eclipse.org/content/java-13-support-eclipse-2019-09- > 413) is marked red but it works/installs just fine. It doesn't install "just fine" in my opinion. It's not at all clear to me up front where it would install just fine... > The entry clearly says > it needs to be installed on top of Eclipse IDE. Firstly, only a human being looks at instructions, and then only occasionally. Obviously the testing process will not look at human-readable instructions but only at the metadata for the listing, i.e., only looking at this: https://marketplace.eclipse.org/content/java-13-support-eclipse-2019-09-413/api/p Not only that, in my opinion, the instructions are also not clear. The instructions point at this: https://download.eclipse.org/eclipse/downloads/drops4/R-4.13-201909161045/ If I download that, the marketplace listing doesn't work because the Platform SDK product does no include marketplace client. As such, one must install marketplace client first (there are no instructions for that) or install a package from the following link, all of which which do include marketplace client. https://www.eclipse.org/downloads/packages/release/2019-09/r But in which of those does the listing actually work? The instructions also mentions that one can use this site directly: https://download.eclipse.org/eclipse/updates/4.13-P-builds But then it fails to mention what from that site should be installed to achieve the goal. All in all, this all seems less than totally clear to me. > The exception stack trace > itself mainly has oomph in the entries. Yes, the test infrastructure uses Oomph so of course the stack trace will include the infrastructure for the test. But it includes the messages produced by p2; for resolution failure this includes the p2 explainer's explanation for why resolution failed. > So, looks like the test does not > just install Eclipse IDE (which of course the test cannot know) and then the > Java support. From this listing's metadata, the test only knows that it should use this site: https://download.eclipse.org/eclipse/updates/4.13-P-builds Based on the listing's declaration that the listing works for 4.13, the test knows/assumes it should use this site in addition: http://download.eclipse.org/releases/2019-09/201909181001 Also based on the listing, it knows that these should be installed (and are both required): <iu required="TRUE">org.eclipse.jdt.java13patch</iu> <iu required="TRUE">org.eclipse.pde.java13patch</iu> But when I try to use marketplace or do this manually (in some arbitrary Eclipse ID), I get "the installation cannot be completed as requested". Showing the original error, it tells me: "Eclipse PDE Patch with Java 13 support for 2019-09 development stream" is not applicable to the current configuration and will not be installed. Why not? No doubt because PDE isn't installed in the Eclipse IDE that I tested. The other choices both include an entry that the Eclipse PDE Patch "will not be installed". It begs the question, why is the PDE thing required at all? Can't I install just Java 13 BETA support without PDE's corresponding support? In any case, I'm not sure what any of the partial failures and subsequent remediation mean; I have quite a bit of expertise in p2 and all this infrastructure, so if I don't know what it means, the average user certainly won't. Does this means something has failed or that something important won't work if I proceed? > If that can't be fixed then there must be a way for MPE > providers to remove that health status icon. I assume that you appreciate all the effort that has gone into doing testing in the first place, so let's get to the bottom of how this actually works (and should actually work) before jumping to conclusions. At this point the only thing that appears to work fine is installing the Eclipse SDK product and manually installing the two features from 4.13-P-builds, making no use the the marketplace listing itself, other than to discover the 4.13-P-builds site. Digging deeper, it appears to be an issue in how the patch IU's metadata is represented. Specifically the lifecyle requirement of the feature patch is non-greedy: <lifeCycle> <required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.jdt.feature.group' range='[3.18.100.v20190916-1045,3.19.0.v20201201-1800)' greedy='false'/> </lifeCycle> If I add a greedy requirement on org.eclipse.jdt.feature.group then resolution succeeds. This took some clever guessing to understand why p2 is complaining about something being missing when that something is definitely available in the update sites being queried... Of course this somehow needs to be automated. So locally I've modified the testing infrastructure to include special case handing of an IInstallableUnitPatch. The code looks at theIInstallableUnitPatch.getLifeCycle() requirement, and adds a non-optional requirement based on that information. With this approach, the resolution succeeds against 2019-09. But hipp6 is down right now, so I can't rebuild the tests and I can't rerun them until Oomph's ci instance is back online. I expect this will make the listing have a green chec kmark for 2019-09. I assume that the listing should not install for 2019-12 so should be changed to exclude that version. In addition, perhaps you should reconsider whether PDE's patch should really be required. The instructions themselves could also be improved.
Created attachment 281239 [details] What happens applying Java 13 Beta to 2019-12 Java IDE package Yes, I don't think making https://marketplace.eclipse.org/content/java-13-support-eclipse-2019-09-413 applicable for 2019-12 makes sense. It appears this would downgrade the JDT feature. Also here you can see why making PDE required is kind of confusing because it's not applicable for the Java IDE package, which seems to me the most likely place that users will apply the listing.
(In reply to Ed Merks from comment #26) > At this point the only thing that appears to work fine is installing the > Eclipse SDK product and manually installing the two features from > 4.13-P-builds, making no use the the marketplace listing itself, other than > to discover the 4.13-P-builds site. As stated, the Eclipse IDE needs to be installed (we could be clearer to mention EPP). Then use the Marketplace client to install it. That works and that's tested by us.
(In reply to Dani Megert from comment #28) > As stated, the Eclipse IDE needs to be installed (we could be clearer to > mention EPP). "Eclipse IDE" is very vague and with only a link to the Eclipse SDK, its even arguably misleading rather than just vague. In the end, the Java 13 Beta patch can only be installed in an "Eclipse IDE" with Java already installed, and not all "Eclipse IDE" packages have Java installed. Even fewer Eclipse IDE packages have PDE installed, so one must ask, why is it required? Even installing the listing in the "Eclipse IDE for Java" is confusing, if you ask me, which you didn't. :-P > Then use the Marketplace client to install it. That works and > that's tested by us. Yes, and the test results now reflect that fact: https://www.eclipse.org/setups/marketplace/?url=https://marketplace.eclipse.org/content/java-13-support-eclipse-2019-09-413 There is still an error because the listing still claims to work for 4.14 <eclipseversion>4.14, 4.13</eclipseversion> That will go away when you update the listing appropriately, i.e., exclude 4.14 which was automatically added if I understand the process correctly. This was apparently be done for this listing: https://www.eclipse.org/setups/marketplace/?url=https://marketplace.eclipse.org/content/java-12-support-eclipse-2019-03-411 Note though that the tests for listings with patch IUs are based on the assumption that the target features are also installed. That's a necessary assumption for automatically testing such things. Specifically for the Java JDT/PDE beta listings, that's not actually a valid assumption for most of the actual Eclipse IDE packages... If I were writing the documentation I would make these things more clear, and I would make the PDE patch not required. But it's your listing and you may of course feel free to document it however you think personally is best. It only caught my attention because you drew my attention to it which forced me to do manual testing to understand what's going on... I imagine that after the 2019-12 release you might want to change the documentation to suggest that users simply update their existing release or install the latest release instead of installing the patch features...
Apparently I'm not the only one who runs into these issues: https://marketplace.eclipse.org/content/java-13-support-eclipse-2019-09-413#bootstrap-panel--2 It's a common theme in the CVS report: Error Report,"Java 13 Support for Eclipse 2019-09 (4.13)","Operation details","Sun, 2019-12-15 22:30","""Eclipse PDE Patch with Java 13 support for 2019-09 development stream"" is not applicable to the current configuration and will not be installed."
(In reply to Pierre-Yves B. from comment #1) > I noticed that this ones seemed "dead": > https://marketplace.eclipse.org/content/eclipse-notepad-plugin > > Though I suspect there will be a better automated way to find all of them. Note that this listing isn't tested at all because it doesn't specify an update site nor things to install from such an update site: https://marketplace.eclipse.org/content/eclipse-notepad-plugin/api/p I.e., there's no <updateurl> element. As such, it's "just advertisement" and there is no "Install" button to drag onto an IDE... It probably shouldn't have the little "heart/health" icon because there's no corresponding report for it...
(In reply to Ed Merks from comment #31) > ... and there is no "Install" button to drag > onto an IDE... I don't know what you are looking at but https://marketplace.eclipse.org/content/java-13-support-eclipse-2019-09-413 clearly has the 'Install' button, which has been tested by my team. > It probably shouldn't have the little "heart/health" icon because there's no > corresponding report for it... Yes, it should be removed! And as you mentioned before, the entry will just point to 4.14 once it's released.
(In reply to Ed Merks from comment #31) > As such, it's "just advertisement" and there is no "Install" button to drag > onto an IDE... I wonder whether those listings should be removed completely from the marketplace. Unsure what there purpose is if they can't be installed. It's more likely to cause confusion than anything else. E.g. on the specific Notepad example, one of the users' comments is "I want to download plugin but i don't know that is how to download,please tell me !".
(In reply to Pierre-Yves B. from comment #33) > (In reply to Ed Merks from comment #31) > > As such, it's "just advertisement" and there is no "Install" button to drag > > onto an IDE... > > I wonder whether those listings should be removed completely from the > marketplace. Unsure what there purpose is if they can't be installed. It can be installed.
(In reply to Dani Megert from comment #32) > (In reply to Ed Merks from comment #31) > > ... and there is no "Install" button to drag > > onto an IDE... > I don't know what you are looking at but Dani, I get the sense that you don't really read everything. You are replying to comment #31 which was a reply to comment #1 which refers to this listing: https://marketplace.eclipse.org/content/eclipse-notepad-plugin This listing does not have an install button and I'm suggesting to Chris Guidon that it might be good to exclude the heart/health icon for listings that don't have an install icon because those listings aren't tested. > https://marketplace.eclipse.org/content/java-13-support-eclipse-2019-09-413 > clearly has the 'Install' button, which has been tested by my team. > Yes, clearly, but also completely unrelated. This listing is tested and I've spent a great many hours on improving the testing infrastructure to deal with feature patches specifically. > > > It probably shouldn't have the little "heart/health" icon because there's no > > corresponding report for it... > Yes, it should be removed! > I don't get it. You still insist that the tests should be removed for your Java 13 beta listing? Why is that? Did you actually read enough to see that I have already addressed your concerns? I don't get the sense that you have done so. Please actually click on this link: https://www.eclipse.org/setups/marketplace/?url=https://marketplace.eclipse.org/content/java-13-support-eclipse-2019-09-413 > > And as you mentioned before, the entry will just point to 4.14 once it's > released. I don't know what you mean by this. Your Java 12 entry did not get changed to point at something different. Please look at it: https://marketplace.eclipse.org/content/java-12-support-eclipse-2019-03-411/api/p It still has: <updateurl> https://download.eclipse.org/eclipse/updates/4.11-P-builds/ </updateurl> <ius> <iu required="TRUE">org.eclipse.jdt.java12patch</iu> <iu required="TRUE">org.eclipse.pde.java12patch</iu> </ius> And it is not documented to suggest updating-to/installing 2019-06 instead. So at this point, you should edit your Java 13 Beta listing to remove the declaration that it supports 4.14 because it does not. The tests say it does not and I tested manually, including attaching a screenshot, to show you that this would uninstall the 4.14 version of JDT. Surely you don't want anyone to do that!
(In reply to Dani Megert from comment #34) > (In reply to Pierre-Yves B. from comment #33) > > (In reply to Ed Merks from comment #31) > > > As such, it's "just advertisement" and there is no "Install" button to drag > > > onto an IDE... > > > > I wonder whether those listings should be removed completely from the > > marketplace. Unsure what there purpose is if they can't be installed. > It can be installed. As I said in the previous reply your "it" and the "it" to which the comments refer are did its. If you don't read the context but only read bits and parts, you will never notice that the issue you raised has been addressed.
(In reply to Pierre-Yves B. from comment #33) > (In reply to Ed Merks from comment #31) > > As such, it's "just advertisement" and there is no "Install" button to drag > > onto an IDE... > > I wonder whether those listings should be removed completely from the > marketplace. Unsure what there purpose is if they can't be installed. It's > more likely to cause confusion than anything else. E.g. on the specific > Notepad example, one of the users' comments is "I want to download plugin > but i don't know that is how to download,please tell me !". Yes, I don't know the actual value of such listings, but I believe marketplace client API doesn't not show such listings in the dialogs, i.e., if I do a search for notepad in the dialog, it only finds your listing. And your listing is well designed to be installable in all versions of Eclipse: https://www.eclipse.org/setups/marketplace/?url=https://marketplace.eclipse.org/content/notepad4e I don't know what processed could be used to remove "stale advertisement listings". I can't imagine how to automate that. :-(
FYI, it struck me this morning that the overall status image for the Java 13 beta listing should be warning and not error. In general, a listing that installs (resolves) successfully in at least one Eclipse version should not be marked as an error. Only if the listing doesn't install/resolve in all Eclipse versions should it be marked with error status. This was a bug in the Javascript for rendering the page and I've committed a fix for that. As such, this listing is now properly displayed with an overall warning: https://www.eclipse.org/setups/marketplace/?url=https://marketplace.eclipse.org/content/java-13-support-eclipse-2019-09-413
Wayne, I think we need a statement from Foundation how are we going to proceed here. Having broken marketplace entries is really bad publicity for Eclipse IDE.
(In reply to Alexander Kurtakov from comment #39) > Wayne, I think we need a statement from Foundation how are we going to > proceed here. Having broken marketplace entries is really bad publicity for > Eclipse IDE. I can propose what my team could here to move this forward: 1. We generate a list of listing id's that are broken. (Ed already did the work for this). 2. My team could send email to all MP listing owners with a broken listing asking them to fix their "dead" entries. We could tell them that we will unpublish their listings in 30 days if they don't fix the problem. The email would also include a link to the report page. For example, https://www.eclipse.org/setups/marketplace/?url=https://marketplace.eclipse.org/content/notepad4e 3. Unpublish dead entries after our deadline. We would also need to implement a solution that would allow listing owners to update and resubmit their unpublished listings to our moderation queue. We currently have 1712 listings on MP, how many do we consider to be "dead" entries? On a different note, I agree that we should remove the heart icon for listings that are not installable. I will work on that today!
(In reply to Christopher Guindon from comment #40) > (In reply to Alexander Kurtakov from comment #39) > > Wayne, I think we need a statement from Foundation how are we going to > > proceed here. Having broken marketplace entries is really bad publicity for > > Eclipse IDE. > > I can propose what my team could here to move this forward: > > 1. We generate a list of listing id's that are broken. (Ed already did the > work for this). > > 2. My team could send email to all MP listing owners with a broken listing > asking them to fix their "dead" entries. We could tell them that we will > unpublish their listings in 30 days if they don't fix the problem. > Up front, perhaps the easiest is to send an email to all listings in the report: https://www.eclipse.org/setups/marketplace/?style=all I.e., for each listing with an actual update site URL (there are currently 1314 of those), send a link to the listing-specific report to make these folks aware that their listing is being tested now. Also make it known that if their listing does not install in any Eclipse version, and that continues to be the case in 30 days, their listing will be automatically removed. It would also be good to make contributors of new listings aware that their listing will be tested without 24 hours of being submitted so that they'll be aware up front about the tests that are in place. > The email would also include a link to the report page. For example, > https://www.eclipse.org/setups/marketplace/?url=https://marketplace.eclipse. > org/content/notepad4e > So yes, but perhaps better to send a link to all listing owners... > 3. Unpublish dead entries after our deadline. > > We would also need to implement a solution that would allow listing owners > to update and resubmit their unpublished listings to our moderation queue. > Yes, it would be annoying if one had to create a completely new listing because the old one was auto-killed... > We currently have 1712 listings on MP, how many do we consider to be "dead" > entries? > This reports shows only the ones with "error" or "warning" style. https://www.eclipse.org/setups/marketplace/?style=error The ones with "error" style don't install anywhere; these should be gone as soon as possible. The ones with "warning" style do install in at least one version of Eclipse; these should be fixed, but auto-killing them is probably not nice. > On a different note, I agree that we should remove the heart icon for > listings that are not installable. I will work on that today! Probably you will need some additional artifacts generated for summary purposes, e.g., to get the list of "error" listings, or some followup on the idea of pushing some data back into the marketplace metadata...
+1 For sending an email to all installable marketplace listings which should be around 1314. To summarize here are the blocker/action items: 1. Implement a mechanism that allow listings owner to manage unpublished listings so that they can fix them and send them back to moderation. 2. Write a draft email that we will send to all installable marketplace listing owners. 3. Create a batch script that will send this email. 4. Unpublish listings after the deadline. > Probably you will need some additional artifacts generated for summary > purposes, e.g., to get the list of "error" listings, or some followup on the > idea of pushing some data back into the marketplace metadata... +1 The conversation around the MP health check endpoint is still open: https://github.com/EclipseFdn/marketplace-rest-api/issues/44 My hope is that we will automate this process in the future. For example, the api receives an error report for a listing. This triggers an email to warn the owner with a deadline to fix it. After the deadline, an email is sent to the listing owner to let them know that their listing is no longer available on MP and that they need to fix it before we can add it back to MP. The owner fix the issue which trigger our testing service to validate the listing. The testing service validate that listing working and add it back to the MP catalog by closing the error report that was sent to the api. ^^This is just an idea..
(In reply to Christopher Guindon from comment #42) > +1 For sending an email to all installable marketplace listings which should > be around 1314. > > To summarize here are the blocker/action items: > > 1. Implement a mechanism that allow listings owner to manage unpublished > listings so that they can fix them and send them back to moderation. > > 2. Write a draft email that we will send to all installable marketplace > listing owners. > > 3. Create a batch script that will send this email. > > 4. Unpublish listings after the deadline. There needs to be a mechanism to mark the entry as good/working.
(In reply to Dani Megert from comment #43) > (In reply to Christopher Guindon from comment #42) > > +1 For sending an email to all installable marketplace listings which should > > be around 1314. > > > > To summarize here are the blocker/action items: > > > > 1. Implement a mechanism that allow listings owner to manage unpublished > > listings so that they can fix them and send them back to moderation. > > > > 2. Write a draft email that we will send to all installable marketplace > > listing owners. > > > > 3. Create a batch script that will send this email. > > > > 4. Unpublish listings after the deadline. > There needs to be a mechanism to mark the entry as good/working. Do you have an example why is this needed?
(In reply to Alexander Kurtakov from comment #44) > Do you have an example why is this needed? See my comments above regarding Java 13 support. A Marketplace entry can also provide (manual) steps how it can/must be installed. Such things can't be automatically tested and flagged.
(In reply to Dani Megert from comment #45) > (In reply to Alexander Kurtakov from comment #44) > > Do you have an example why is this needed? > See my comments above regarding Java 13 support. A Marketplace entry can > also provide (manual) steps how it can/must be installed. Such things can't > be automatically tested and flagged. Sorry but all I see is "This marketplace solution is no longer needed/offered as Java 13 support is now part of Eclipse 2019-12 (4.14)." on https://marketplace.eclipse.org/content/java-13-support-eclipse-2019-09-413 thus this examples doesn't help me understand at all.
(In reply to Alexander Kurtakov from comment #46) > (In reply to Dani Megert from comment #45) > > (In reply to Alexander Kurtakov from comment #44) > > > Do you have an example why is this needed? > > See my comments above regarding Java 13 support. A Marketplace entry can > > also provide (manual) steps how it can/must be installed. Such things can't > > be automatically tested and flagged. > > Sorry but all I see is "This marketplace solution is no longer > needed/offered as Java 13 support is now part of Eclipse 2019-12 (4.14)." on > https://marketplace.eclipse.org/content/java-13-support-eclipse-2019-09-413 > thus this examples doesn't help me understand at all. Actually looking at the listing now it's exactly the type of listing that should be removed in its current state. Sarika, would you please drop the listing directly?
(In reply to Alexander Kurtakov from comment #47) > (In reply to Alexander Kurtakov from comment #46) > > (In reply to Dani Megert from comment #45) > > > (In reply to Alexander Kurtakov from comment #44) > > > > Do you have an example why is this needed? > > > See my comments above regarding Java 13 support. A Marketplace entry can > > > also provide (manual) steps how it can/must be installed. Such things can't > > > be automatically tested and flagged. > > > > Sorry but all I see is "This marketplace solution is no longer > > needed/offered as Java 13 support is now part of Eclipse 2019-12 (4.14)." on > > https://marketplace.eclipse.org/content/java-13-support-eclipse-2019-09-413 > > thus this examples doesn't help me understand at all. > > Actually looking at the listing now it's exactly the type of listing that > should be removed in its current state. Sarika, would you please drop the > listing directly? I made the comments when the entry was still valid and 2019-12 not yet there ;-). And yes, now it would be fine to remove it.
Note that the problem with testing patch features was fixed so the next time JDT has a patch listing, it should be properly tested.
(In reply to Ed Merks from comment #49) > Note that the problem with testing patch features was fixed so the next time > JDT has a patch listing, it should be properly tested. OK.
New Gerrit change created: https://git.eclipse.org/r/157841
Gerrit change https://git.eclipse.org/r/157841 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=92db59cd8fd68b0727ba293cd22ff5d35a82fcba
*** Bug 553628 has been marked as a duplicate of this bug. ***
Christopher / Ed, what is the current status? Did we remove the invalid solution listings?
Actually removing listing hasn't seemed to make any progress...
(In reply to Ed Merks from comment #55) > Actually removing listing hasn't seemed to make any progress... To be honest, my team is swamp but let me see if I can someone to look at this in the next 2 weeks. Requirements: 1. Implement a mechanism that allows listings owner to manage unpublished listings so that they can fix them and send them back to moderation. 2. Write a draft email that we will send to all installable marketplace listing owners. 3. Create a batch script that will send this email. 4. Unpublish listings after the deadline. 5. Built a mechanism that will allow listings owners to mark their listing as functional. See comment https://bugs.eclipse.org/bugs/show_bug.cgi?id=550713#c43
Hi everyone, We are planning to send an email to all listing owners to let them know that we would like to unpublish invalid listings. We started a draft for that email which you can find here: https://docs.google.com/document/d/1MVEhdH0BTtNLQCpsq9zTxOfzqU4jPIzx_tWwPcpwqqg/edit You are more then welcome to have a look and let us know if you'd like to make changes to that email. The reason why we decided to send an email to all listing owners rather than owners of installable listings only is because we already have a tool to send emails to all listing owners. By using that tool would save us some time. A patch is also under review to make it so that listing owners can see their unpublished listings in their My Marketplace: https://marketplace.eclipse.org/user/[PersonID]/listings Note that the email will be sent only when the patch has been merged to production. Let me know if you have any questions. Thanks.
(In reply to Eric Poirier from comment #57) > Hi everyone, > > We are planning to send an email to all listing owners to let them know that > we would like to unpublish invalid listings. Thanks Eric for pushing this forward! > A patch is also under review to make it so that listing owners can see their > unpublished listings in their My Marketplace: > https://marketplace.eclipse.org/user/[PersonID]/listings A sharable link for this page would be: https://marketplace.eclipse.org/user
I've requested access to the document...
(In reply to Ed Merks from comment #59) > I've requested access to the document... @Eric, can you make your document accessible for all? I think we can also allow everyone to suggest edits if possible!
(In reply to Ed Merks from comment #59) > I've requested access to the document... Me too.
(In reply to Christopher Guindon from comment #60) > (In reply to Ed Merks from comment #59) > > I've requested access to the document... > > @Eric, can you make your document accessible for all? > > I think we can also allow everyone to suggest edits if possible! Is this accessible to all now? https://docs.google.com/document/d/1MVEhdH0BTtNLQCpsq9zTxOfzqU4jPIzx_tWwPcpwqqg/edit?usp=sharing
I updated the document with the comments that were left in it. Is it ready to be sent? Thanks.
(In reply to Eric Poirier from comment #63) > I updated the document with the comments that were left in it. Is it ready > to be sent? > > Thanks. +1
(In reply to Eric Poirier from comment #63) > I updated the document with the comments that were left in it. Is it ready > to be sent? > > Thanks. Since the last couple of days, the number of listings being processed has dropped down to a handful: I.e., from this in the log Listing count: 1856 Gathering 186 categories: 0 Gathering 18634 listings: 937 To this in the log: Listing count: 20 Gathering 2 categories: 0 Gathering 140 listings: 11 I'll need to investigate what has changed recently to cause this. That might take a few days. Please don't send it until the report is complete again.
The problem is that the following link no longer yields all the listing: https://marketplace.eclipse.org/api/p/search/apachesolr_search/%20 This was kind of a hack, but something changed to make even that not work. Did you change something? Can you change it back? I need a way to get all the listing...
(In reply to Ed Merks from comment #66) > The problem is that the following link no longer yields all the listing: > > https://marketplace.eclipse.org/api/p/search/apachesolr_search/%20 > > This was kind of a hack, but something changed to make even that not work. > Did you change something? Can you change it back? > > I need a way to get all the listing... I recently made some changes to try to improve performance on the site and one did change how the search was working. https://bugs.eclipse.org/bugs/show_bug.cgi?id=564056 I reverted that change today.
(In reply to Christopher Guindon from comment #67) > I recently made some changes to try to improve performance on the site and > one did change how the search was working. > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=564056 > > I reverted that change today. Okay, that did the trick. The URL https://www.eclipse.org/setups/marketplace/?style=all now yields this again: There are a total of 1330 listings, 563 of which contain errors or warnings. So it's ready for prime time consumption again. Thanks!
Did we make progress here?
(In reply to Lars Vogel from comment #69) > Did we make progress here? I don't think so. Currently the summary is: There are a total of 1344 listings, 559 of which contain errors or warnings So there are more listing though slightly fewer errors. Note that I added 2020-06 as one of the tested versions.
Hi everyone, I would like to merge a patch tomorrow to let users access their unpublished content on the Marketplace website and then send the email to all listing owners. I updated the unpublishing date to September 1, 2020 (let me know if that's an issue). Thanks!
(In reply to Eric Poirier from comment #71) > Hi everyone, > > I would like to merge a patch tomorrow to let users access their unpublished > content on the Marketplace website and then send the email to all listing > owners. I updated the unpublishing date to September 1, 2020 (let me know if > that's an issue). > > Thanks! Let's plan on sending the email on August 18 with a September 21 deadline.
My patch to add unpublished listings to the list of user's listings is now on production and it has been tested. User's are now able to see their unpublished listings in their "My Marketplace" section. On Tuesday I will be sending user's the email containing the following text: https://docs.google.com/document/d/1MVEhdH0BTtNLQCpsq9zTxOfzqU4jPIzx_tWwPcpwqqg/edit Let me know if you have any questions. Thanks.
An email as been sent this morning to all listing owners to let them know about our plan. The content of the email is the following: https://docs.google.com/document/d/1MVEhdH0BTtNLQCpsq9zTxOfzqU4jPIzx_tWwPcpwqqg/edit Next step is to unpublish listings on September 21, 2020. Let me know if you have any questions. Thanks.
*** Bug 566655 has been marked as a duplicate of this bug. ***
Hi Ed, Can you provide us a list of all the listings that needs to be deleted. This will help me to unpublish those listings quickly. Thanks.
Created attachment 284246 [details] A "list" of all the listings whose update site doesn't load I'm not sure the form in which you want the information. The attached XML is a report of just the listings whose update site simply doesn't load. Perhaps we start by de-listing these and progress to the ones that fail for other reasons?
(In reply to Ed Merks from comment #77) > Created attachment 284246 [details] > A "list" of all the listings whose update site doesn't load > > I'm not sure the form in which you want the information. > > The attached XML is a report of just the listings whose update site simply > doesn't load. Perhaps we start by de-listing these and progress to the ones > that fail for other reasons? This means that we will be removing ~18-16% of the current list of listings. Are we sure we want to do this?
I've updated this page slightly to display the number of errors and warnings: https://www.eclipse.org/setups/marketplace/?style=all It summarizes the following: There are a total of 1354 listings, 399 of which contain errors and 169 of which contain warnings. The listings flagged as errors do not successfully resolve for any version of Eclipse. The ones with only warnings resolve successfully for at least one version of Eclipse. So yes, almost 30% of the listings simply don't ever work. And yes, the listings for which the p2 update site never loads (the ones in the attachment) would be great to remove as a first step. This will dramatically improve the job for generating this data, because many of these sites have long timeouts and it's a waste of time to keep testing them.
I made some more improvements to the page. In particular, the navigation bar now has links for all the different styles of reports available. In addition, the navigation header section named "Reports" has two icons in front of it. The first pencil glyph will copy a report summary to the clipboard. The second down-arrow/download glyph will download the report summary. This way I don't need to send you reports but you can collect them on demand... I think we should start with delisting the ones for this report: https://www.eclipse.org/setups/marketplace/?style=site-error
(In reply to Ed Merks from comment #79) > I've updated this page slightly to display the number of errors and warnings: > > https://www.eclipse.org/setups/marketplace/?style=all > > It summarizes the following: > > There are a total of 1354 listings, 399 of which contain errors and 169 of > which contain warnings. > > The listings flagged as errors do not successfully resolve for any version > of Eclipse. The ones with only warnings resolve successfully for at least > one version of Eclipse. > > So yes, almost 30% of the listings simply don't ever work. And yes, the > listings for which the p2 update site never loads (the ones in the > attachment) would be great to remove as a first step. This will > dramatically improve the job for generating this data, because many of these > sites have long timeouts and it's a waste of time to keep testing them. Thanks Ed! I wanted to make sure before we make this change. @eric, please make sure to use this report: https://www.eclipse.org/setups/marketplace/?style=site-error
We've unpublished all listings from your report Ed.
(In reply to Christopher Guindon from comment #82) > We've unpublished all listings from your report Ed. Closing this issue!
