Community
Participate
Working Groups
Since I remember, they have been always in Eclipse. It looks like they have been introduced to support Eclipse 2.0 model, and has been marked as @deprecated in 2004 (actually TODO: @deprecated was replaced with @deprecated at that time). If it happens there is someone that uses those plugins, they should either migrate to 3.x style or include those bundles into their features.
+1 Cleanup work is good
AFAIK, at least PDE is still using this.
Yes we already decided to remove this API (see bug 370248) we currently have a policy of giving two years advance notice of removals so this can be done in 2014. Meanwhile it is not doing much harm and has little/no effect if you are not using it. I will keep this bug open to track the actual removal.
Two years are over, can we remove them for Luna? https://git.eclipse.org/r/21622
I'm all for removing it (them?) I did not see org.eclipse.core.runtime.compatibility.auth used anywhere (in pom or feature.xml files ... so it could probably just be removed from master branch ... make sure some version of it has a clean 'tag' so we can document "last used version" here. But, the other two, I see in many poms and feature.xmls ... so will take a coordinated effort. (The ones in p2.tests may be pre-compiled versions, used to test compatibility with previous releases, so not sure they need to be removed. org.eclipse.equinox.p2.tests org.eclipse.help.webapp org.eclipse.pde.build org.eclipse.platform-feature org.eclipse.test-feature eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/pom.xml: <artifactId>org.eclipse.core.runtime.compatibility</artifactId> eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv/pom.xml: <artifactId>org.eclipse.core.runtime.compatibility</artifactId> eclipse.platform.common/bundles/org.eclipse.jdt.doc.user/pom.xml: <artifactId>org.eclipse.core.runtime.compatibility</artifactId> eclipse.platform.common/bundles/org.eclipse.platform.doc.user/pom.xml: <artifactId>org.eclipse.core.runtime.compatibility</artifactId> eclipse.platform.common/bundles/org.eclipse.pde.doc.user/pom.xml: <artifactId>org.eclipse.core.runtime.compatibility</artifactId> eclipse.platform.runtime/bundles/org.eclipse.core.runtime.compatibility/pom.xml: <artifactId>org.eclipse.core.runtime.compatibility</artifactId> eclipse.platform.runtime/bundles/org.eclipse.core.runtime.compatibility.registry/pom.xml: <artifactId>org.eclipse.core.runtime.compatibility.registry</artifactId> eclipse.platform.runtime/bundles/org.eclipse.core.runtime.compatibility.auth/pom.xml: <artifactId>org.eclipse.core.runtime.compatibility.auth</artifactId> eclipse.platform.runtime/pom.xml: <module>bundles/org.eclipse.core.runtime.compatibility</module> eclipse.platform.runtime/pom.xml: <module>bundles/org.eclipse.core.runtime.compatibility.registry</module> rt.equinox.framework/bundles/org.eclipse.osgi.tests/pom.xml: <artifactId>org.eclipse.core.runtime.compatibility.registry</artifactId>
Added Tom Watson, Ian, and Pascal to CC list ... Dani and John are already on it ... so please "weigh in" on when you think best time is to have a "coordinated removal".
(In reply to David Williams from comment #6) > Added Tom Watson, Ian, and Pascal to CC list ... Dani and John are already > on it ... so please "weigh in" on when you think best time is to have a > "coordinated removal". We are all very busy, so, I'd prefer to avoid such swirls unless it is something with a big impact, e.g. getting performance tests up and running again.
(In reply to Dani Megert from comment #7) > (In reply to David Williams from comment #6) > > Added Tom Watson, Ian, and Pascal to CC list ... Dani and John are already > > on it ... so please "weigh in" on when you think best time is to have a > > "coordinated removal". > > We are all very busy, so, I'd prefer to avoid such swirls unless it is > something with a big impact, e.g. getting performance tests up and running > again. I think there is little connection to performance tests effort ... except I will say the more "technical debt" we carry along, the harder it is to do "releng work" ... though in this case, as I said, little impact, one way or the other on that specific issue. Though it is always interesting to see before and after performance differences :)
If org.eclipse.core.runtime.compatibility.auth is removable without work can't it be removed and the rest left for later and interested people can look into reducing references to org.eclipse.core.runtime.compatibility for later removal?
(In reply to David Williams from comment #5) > rt.equinox.framework/bundles/org.eclipse.osgi.tests/pom.xml: > <artifactId>org.eclipse.core.runtime.compatibility.registry</artifactId> I'm pretty sure this can be removed from the osgi.tests pom.xml. Perhaps I should just do it and see if the tests break. But I must say I don't understand what this part of the pom.xml is doing and I don't see similar sections in other test project pom.xml files. It seems to be indicating the testSuite, testClass and the dependencies needed to run it?
To proceed with the removal, my recommendation would be the following: 1 - remove the plugin from the build 2 - keep it in the repo and and aggregation - just in case some legacy plug-in need it 3 - add a way to track the download stat of this plugin so we know if it is ever used (though I suspect we would end up seeing "usage" because of ppl doing mirrors of repos for internal builds)
(In reply to Pascal Rapicault from comment #11) > To proceed with the removal, my recommendation would be the following: > 1 - remove the plugin from the build > 2 - keep it in the repo and and aggregation - just in case some legacy > plug-in need it > 3 - add a way to track the download stat of this plugin so we know if it is > ever used (though I suspect we would end up seeing "usage" because of ppl > doing mirrors of repos for internal builds) I sympathize with your goals of protecting adopter's investments, but a) this starts to sound like more of work (for me) and b) sounds counter to the concept of deprecating an API and removing it two years later. I think it would suffice that if someone needed it, they could get it from an old repository ... such as from Kepler. (4.3.x). [Granted ... I know little about its technical aspects, but assuming it's not changed at all in two years.]
(In reply to Alexander Kurtakov from comment #9) > If org.eclipse.core.runtime.compatibility.auth is removable without work > can't it be removed and the rest left for later and interested people can > look into reducing references to org.eclipse.core.runtime.compatibility for > later removal? Updated my Gerrit review to remove only org.eclipse.core.runtime.compatibility.auth https://git.eclipse.org/r/#/c/21622/ For the other two plug-ins, I agree we should try to reduce their usage over time so that we finally can delete them.
> I sympathize with your goals of protecting adopter's investments, but a) > this starts to sound like more of work (for me) and b) sounds counter to the > concept of deprecating an API and removing it two years later. I'm not trying to protect the adopters as much as the users. In the end there are still a lot of plugins out there that are no longer maintained but still install properly and could have added a dependency on this. But if it is too much work on the releng side, let's remove it purely and simply. After all this plugin does not contain much interesting content, and its content was something that was not really used anyway.
Now that I've successfully advocated the removal of these "compatibility" bundles ... maybe I should ask, "what are they for"? :) I'm assuming these are for the "Eclipse 2.x" era bundles that have to be converted to OSGi bundles "on the fly". If that's not the case, let me know. (I thought of asking for better understanding since I realized some people still partially count on the old "site.xml" update sites ... and wanted to be sure that's not what this was about ... that support is still "in", right? And, even if it wasn't, that'd be ok ... but then I would just want to be sure some specific projects were made aware of it, so they could adjust, if they haven't already). Thanks,
(In reply to David Williams from comment #15) > Now that I've successfully advocated the removal of these "compatibility" > bundles ... maybe I should ask, "what are they for"? :) > > I'm assuming these are for the "Eclipse 2.x" era bundles that have to be > converted to OSGi bundles "on the fly". IMHO this is correct. AFAIK these are to run unmodified Eclipse 2.x components on top of Eclipse 3.x / 4.x.
It also includes the 2.x API that exposed the content of the plugin.xml, or the bootstrap API.
(In reply to David Williams from comment #15) > I'm assuming these are for the "Eclipse 2.x" era bundles that have to be > converted to OSGi bundles "on the fly". > These particular bundles do not do any converting of OSGi bundles "on the fly". As Pascal mentioned, they are providing old API impls from Eclipse 2.0.
(In reply to Lars Vogel from comment #13) > Updated my Gerrit review to remove only > org.eclipse.core.runtime.compatibility.auth > > https://git.eclipse.org/r/#/c/21622/ Any objections to delete the not used org.eclipse.core.runtime.compatibility.auth plug-in? If not I remove it within the next days.
org.eclipse.core.runtime.compatibility.auth deleted with https://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=9c85295f0b0431a27bf4108ae28cf25fc3f7dec4
(In reply to Pascal Rapicault from comment #14) > I'm not trying to protect the adopters as much as the users. In the end > there are still a lot of plugins out there that are no longer maintained but > still install properly and could have added a dependency on this. > > But if it is too much work on the releng side, let's remove it purely and > simply. After all this plugin does not contain much interesting content, and > its content was something that was not really used anyway. I find it kind of hard to believe that there are many users still using the same old unmaintained plugins, have been using them for the past 10 years, but are also using up-to-date Eclipse releases. And it's not like they are forced to update Eclipse anyway :-) So either they are really interested in those plugins and having them work on Luna, and do something so that they or someone else update them (I don't expect that removing calls/dependencies to a deprecated API would be too hard to do, unless these plugins were doing something dirty in the first place); or they don't update to Luna; or they stop using outdated plugins.
(In reply to Lars Vogel from comment #20) > org.eclipse.core.runtime.compatibility.auth deleted with > https://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/ > ?id=9c85295f0b0431a27bf4108ae28cf25fc3f7dec4 This fix is not complete because there are still references to org.eclipse.core.runtime.compatibility.auth (e.g. in org.eclipse.core.runtime\META-INF\MANIFEST.MF and also in other places) so these should be removed as well before closing this bug.
(In reply to Szymon Ptaszkiewicz from comment #22) > This fix is not complete because there are still references to > org.eclipse.core.runtime.compatibility.auth (e.g. in > org.eclipse.core.runtime\META-INF\MANIFEST.MF and also in other places) so > these should be removed as well before closing this bug. Removed MANIFEST.MF dependency in core.runtime with https://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=ca4583e3db44b095c9c9bbb852a09cf58efd7686 > and also in other places Let me know if you see more usages, I could not find any. I think we can now also simplify AuthorizationHandler, I open Bug 439315 for that.
(In reply to Lars Vogel from comment #23) > Let me know if you see more usages, I could not find any. You can run full text search with "org.eclipse.core.runtime.compatibility.auth" as the query against repos listed here http://download.eclipse.org/eclipse/downloads/drops4/N20140709-2000/directory.txt Then you will know if there is any remaining reference in SDK.
And the service segment of modified bundles needs to be set to the next hundred (for bundles that have not yet been touched for Mars): https://wiki.eclipse.org/Version_Numbering#When_to_change_the_service_segment Releng Tools will also tell you where to update the pom.xml.
Remove org.eclipse.core.runtime.compatibility from org.eclipse.ui.tests with https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=947977b7bc4ca8d6792f36a6d8253f05f4927a7b
Hi Lars, I would like to start submitting patches towards this bug as noted on bug 419524 :-)
(In reply to Mat Booth from comment #27) > Hi Lars, > > I would like to start submitting patches towards this bug as noted on bug > 419524 :-) Eagerly awaiting your deletion patches. :-)
New Gerrit change created: https://git.eclipse.org/r/41944
(In reply to Eclipse Genie from comment #29) > New Gerrit change created: https://git.eclipse.org/r/41944 This is a small patch to remove usage of core.runtime.compat bundles in eclipse.platform.ui.
Gerrit change https://git.eclipse.org/r/41944 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=8afaf18b4825fbbd0111c9e200c8e3b2b5710aeb
(In reply to Mat Booth from comment #30) > (In reply to Eclipse Genie from comment #29) > > New Gerrit change created: https://git.eclipse.org/r/41944 > > This is a small patch to remove usage of core.runtime.compat bundles in > eclipse.platform.ui. Thanks Mat. Merged
New Gerrit change created: https://git.eclipse.org/r/41954
(In reply to Eclipse Genie from comment #33) > New Gerrit change created: https://git.eclipse.org/r/41954 Another small patch to remove usage of core.runtime.compat bundles, but in eclipse.platform.resources this time.
Gerrit change https://git.eclipse.org/r/41954 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=46af2891d781be3a29987d296edae97d13d93877
New Gerrit change created: https://git.eclipse.org/r/42093
I see that Andrey tried to update the bundles we are planning to remove in Bug 460048. I think we should go ahead and delete them. https://git.eclipse.org/r/42093 Mat, can you search for remaining references and remove them? They should be optional so even if we delete the bundles this should not affect the build (in theory). (Shame that the runtime Gerrit build trigger still does not work).
The following command does not find any more references if I run it in the eclipse.platform.releng.aggregator repo: find . -name "*" | grep "org.eclipse.core.runtime.compatibility*"
Gerrit change https://git.eclipse.org/r/42093 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=067e83f6967052939fe599e6ff5bda3dbbfa2a63
(In reply to Eclipse Genie from comment #39) > Gerrit change https://git.eclipse.org/r/42093 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/ > ?id=067e83f6967052939fe599e6ff5bda3dbbfa2a63 This removes the bundles. Marking this bug as fixed. Thanks Mat for the help.
Please remove references to the bundles in eclipse.platform.runtime/pom.xml too. This way it breaks maven builds.
New Gerrit change created: https://git.eclipse.org/r/42103
(In reply to Alexander Kurtakov from comment #41) > Please remove references to the bundles in eclipse.platform.runtime/pom.xml > too. This way it breaks maven builds. Thanks. Looks like I have to work on my not so awesome Linux command line skills. grep -r "org.eclipse.core.runtime.compatibility" shows still several references.
New Gerrit change created: https://git.eclipse.org/r/42107 WARNING: this patchset contains 9212 new lines of code and may require a Contribution Questionnaire (CQ) if the author is not a committer on the project. Please see:https://wiki.eclipse.org/Project_Management_Infrastructure/Creating_A_Contribution_Questionnaire
Gerrit change https://git.eclipse.org/r/42107 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=cc69be4018d62f40622df355aa9728c719c78c7b WARNING: this patchset contains 9212 new lines of code and may require a Contribution Questionnaire (CQ) if the author is not a committer on the project. Please see:https://wiki.eclipse.org/Project_Management_Infrastructure/Creating_A_Contribution_Questionnaire
(In reply to Lars Vogel from comment #43) > grep -r "org.eclipse.core.runtime.compatibility" > shows still several references. I restored the bundles so that we can safely remove all references to them before deleting them. Sorry for the noise.
New Gerrit change created: https://git.eclipse.org/r/42113
(In reply to Eclipse Genie from comment #47) > New Gerrit change created: https://git.eclipse.org/r/42113 Remove references from "eclipse.platform.team" project.
Gerrit change https://git.eclipse.org/r/42113 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=1bf1c17ab4070679d47112a2a69ba3967e27c508
New Gerrit change created: https://git.eclipse.org/r/42296
New Gerrit change created: https://git.eclipse.org/r/42297
Gerrit change https://git.eclipse.org/r/42297 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=934a668e3511baa3d35b21659d977c634f54f2f1
Gerrit change https://git.eclipse.org/r/42296 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ua.git/commit/?id=620f900d81a9f3fc4c3f327cce430f73d5ddf152
(In reply to Eclipse Genie from comment #35) > Gerrit change https://git.eclipse.org/r/41954 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/ > ?id=46af2891d781be3a29987d296edae97d13d93877 Mat, this one needs more work. The commit removed dependency on org.eclipse.core.runtime.compatibility but now the project violates the javadoc rule for IPluginRegistry and IPluginDescriptor: "This interface must only be used by plug-ins which explicitly require the org.eclipse.core.runtime.compatibility plug-in." Can you please provide a follow up patch to fix this? Thanks!
New Gerrit change created: https://git.eclipse.org/r/42383
(In reply to Eclipse Genie from comment #55) > New Gerrit change created: https://git.eclipse.org/r/42383 Hi Szymon, you're absolutely right. I submitted this change to fix the tests.resources.saveparticipant plug-ins.
(In reply to Mat Booth from comment #56) > Hi Szymon, you're absolutely right. I submitted this change to fix the > tests.resources.saveparticipant plug-ins. Please see the Szymons comments in the review and update it.
Gerrit change https://git.eclipse.org/r/42383 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=6e7b01a93ef5f18648709aa2dafc4d47948fc7a9
New Gerrit change created: https://git.eclipse.org/r/44171
(In reply to Eclipse Genie from comment #59) The commit reverted in observance of the M6 week. Will resubmit once M6 is out.
Gerrit change https://git.eclipse.org/r/44171 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=a67c5a0906e7213d366c6f5826ab54c976af195a
New Gerrit change created: https://git.eclipse.org/r/44172
(In reply to Sergey Prigogin from comment #60) > (In reply to Eclipse Genie from comment #59) > The commit reverted in observance of the M6 week. Will resubmit once M6 is > out. Thank you! (I was just getting ready to ask :)
Gerrit change https://git.eclipse.org/r/44172 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=74751ade0222e7a1557937bf39817a63ea6c0749
(In reply to Eclipse Genie from comment #64) Resubmitted.
(In reply to Lars Vogel from comment #46) > (In reply to Lars Vogel from comment #43) > > grep -r "org.eclipse.core.runtime.compatibility" > > shows still several references. > > I restored the bundles so that we can safely remove all references to them > before deleting them. Sorry for the noise. Lars, what is the state of the patch? What is need to be done? Is it true that what need to be removed are the plugins below? org.eclipse.core.runtime.compatibility org.eclipse.core.runtime.compatibility.registry I'm missing something? Should I create removal patch?
(In reply to Andrey Loskutov from comment #66) > (In reply to Lars Vogel from comment #46) > > (In reply to Lars Vogel from comment #43) > > > grep -r "org.eclipse.core.runtime.compatibility" > > > shows still several references. > > > > I restored the bundles so that we can safely remove all references to them > > before deleting them. Sorry for the noise. > > Lars, what is the state of the patch? What is need to be done? > Is it true that what need to be removed are the plugins below? > > org.eclipse.core.runtime.compatibility > org.eclipse.core.runtime.compatibility.registry > > I'm missing something? Should I create removal patch? There are still some usages that need to be removed first. See, for example, bug 462201 At this point, I'd say that these can't be removed before Mars.
Sopot, you assigned that bug to you. What is the status here? Can you remove the bundles? The old code seems to cause NPEs, see Bug 473929.
(In reply to Lars Vogel from comment #68) > Sopot, you assigned that bug to you. What is the status here? Can you remove > the bundles? The old code seems to cause NPEs, see Bug 473929. Yes I took this over from Mat but just started to look at it this afternoon and I'm skimming through the history of the bug.
Sopot, all prerequisites are resolved, I think you can go ahead and remove these bundles.
*** Bug 474820 has been marked as a duplicate of this bug. ***
(In reply to Lars Vogel from comment #70) > Sopot, all prerequisites are resolved, I think you can go ahead and remove > these bundles. I'm getting a warning to bump the version of org.eclipse.core.runtime(In reply to Lars Vogel from comment #70) > Sopot, all prerequisites are resolved, I think you can go ahead and remove > these bundles. I get an error which wants me to bump the major version of org.eclipse.core.runtime to 4 because of the API breakage. That in turn has some complications as platform.ui bundles have the [.., 4.0) version constraint. I'll investigate a bit further.
(In reply to Sopot Cela from comment #72) > I get an error which wants me to bump the major version of > org.eclipse.core.runtime to 4 because of the API breakage. That in turn has > some complications as platform.ui bundles have the [.., 4.0) version > constraint. I'll investigate a bit further. I kept getting similar problems locally for different plugins which seems to be caused by bug 449102. In general, strange things happen in your workspace when you use I20150818-0800 so I think it's better to wait for today's I-build and test on it before you commit anything.
(In reply to Sopot Cela from comment #72) > I get an error which wants me to bump the major version of > org.eclipse.core.runtime to 4 because of the API breakage. That in turn has > some complications as platform.ui bundles have the [.., 4.0) version > constraint. I'll investigate a bit further. If this remains I would suggest to use an API filter for these messages. The support for these plug-ins has long been terminated.
Ok the new I-build doesn't seem to show the error to require the major bump. I'll split this in two gerrits for two repos: - platform.runtime which will delete bundles and update the poms - platform.releng which will update the features Patchsets incoming.
New Gerrit change created: https://git.eclipse.org/r/54595
New Gerrit change created: https://git.eclipse.org/r/54596
(In reply to Sopot Cela from comment #75) > - platform.runtime which will delete bundles and update the poms > - platform.releng which will update the features Do we have to sync the release of both patches to avoid a build breakage?
(In reply to Lars Vogel from comment #78) > (In reply to Sopot Cela from comment #75) > > - platform.runtime which will delete bundles and update the poms > > - platform.releng which will update the features > > Do we have to sync the release of both patches to avoid a build breakage? I think so, though I have no idea how to do that.
(In reply to Sopot Cela from comment #79) > (In reply to Lars Vogel from comment #78) > > (In reply to Sopot Cela from comment #75) > > > - platform.runtime which will delete bundles and update the poms > > > - platform.releng which will update the features > > > > Do we have to sync the release of both patches to avoid a build breakage? > > I think so, though I have no idea how to do that. Should be removed from features, first. That won't break the build.
Gerrit change https://git.eclipse.org/r/54596 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.git/commit/?id=b7f4c4295be955a5520c9bcdd4cef8aded059d81
(In reply to David Williams from comment #80) > (In reply to Sopot Cela from comment #79) > > (In reply to Lars Vogel from comment #78) > > > (In reply to Sopot Cela from comment #75) > > > > - platform.runtime which will delete bundles and update the poms > > > > - platform.releng which will update the features > > > > > > Do we have to sync the release of both patches to avoid a build breakage? > > > > I think so, though I have no idea how to do that. > > Should be removed from features, first. That won't break the build. Be sure you check "docs" too (if you haven't already).
New Gerrit change created: https://git.eclipse.org/r/54633
(In reply to Eclipse Genie from comment #83) > New Gerrit change created: https://git.eclipse.org/r/54633 This change removes references to the compat bundles from the platform javadoc generation options.
Gerrit change https://git.eclipse.org/r/54633 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=de616e718df50067f3130488f049958024fc33cc
New Gerrit change created: https://git.eclipse.org/r/54675
Gerrit change https://git.eclipse.org/r/54675 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=af118e2e2733c18bac1daf19b2803f8fb2c2f70b
Gerrit change https://git.eclipse.org/r/54595 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=7db97c8d826937dab8c3b744e5179302763a6dab
New Gerrit change created: https://git.eclipse.org/r/54739
Gerrit change https://git.eclipse.org/r/54739 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?id=4c1b71edc5f460ce4dc183f592449b24dbe53c97
There's more fallout from those changes: 1. 2 test failures in PreferenceExportTest http://download.eclipse.org/eclipse/downloads/drops4/N20150829-1500/testresults/html/org.eclipse.core.tests.runtime_linux.gtk.x86_64_8.0.html There are still references to Platform.getPlugin(String) in the SDK org.eclipse.ui.actions.CopyProjectAction.getPlugin() org.eclipse.ui.views.bookmarkexplorer.BookmarkNavigator.getPlugin() org.eclipse.ui.views.tasklist.TaskList.getPlugin() org.eclipse.core.internal.preferences.legacy.InitLegacyPreferences.init(Object, String) org.eclipse.ui.texteditor.WorkbenchChainedTextFontFieldEditor.startPropagate(IPreferenceStore, String) org.eclipse.core.tests.runtime.PreferenceExportTest.tearDown() org.eclipse.core.tests.runtime.PreferenceExportTest.testExportEmptyPreference() org.eclipse.core.tests.runtime.PreferenceExportTest.testKeyIdentityAfterExport() org.eclipse.ui.editors.text.TextEditorPreferencePage.TextEditorPreferencePage() which now returns 'null' and causes lots of issues. Those things need to get fixed ASAP. 2. BuildTests.testJavadocLogs fails: javadoc: warning - No source files for package org.eclipse.core.runtime.model javadoc: warning - No source files for package org.eclipse.core.runtime.model 2 warnings
(In reply to Dani Megert from comment #91) > There's more fallout from those changes: > There are still references to Platform.getPlugin(String) in the SDK This is most likely also the cause for all the test failures in the ui.tests: http://download.eclipse.org/eclipse/downloads/drops4/N20150829-1500/testresults/html/org.eclipse.ui.tests_linux.gtk.x86_64_8.0.html
New Gerrit change created: https://git.eclipse.org/r/54852
Gerrit change https://git.eclipse.org/r/54852 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=17a25db6d50adeb3498b536c24c7ca196d6636d5
New Gerrit change created: https://git.eclipse.org/r/54907
New Gerrit change created: https://git.eclipse.org/r/54912
Gerrit change https://git.eclipse.org/r/54907 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=37134c0f43aa708131733fa3e1a6b87b02423c91
Removed references in doc, see https://wiki.eclipse.org/How_to_add_things_to_the_Eclipse_doc : http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=c548e637a74d440b193eb867f1ae95224971c1f4
Gerrit change https://git.eclipse.org/r/54912 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=441c5e9588f3510ca54f67abb1b35a765e3115ec
There are still 9 failures: http://download.eclipse.org/eclipse/downloads/drops4/N20150903-2000/testresults/html/org.eclipse.ui.tests_linux.gtk.x86_64_8.0.html
(In reply to Dani Megert from comment #100) > There are still 9 failures: > > http://download.eclipse.org/eclipse/downloads/drops4/N20150903-2000/ > testresults/html/org.eclipse.ui.tests_linux.gtk.x86_64_8.0.html Yes, we are aware of them and working through them. Having tests run successfully only on really strict set of platforms makes us wait for the N-build to see what's left.
New Gerrit change created: https://git.eclipse.org/r/55262
New Gerrit change created: https://git.eclipse.org/r/55273
Gerrit change https://git.eclipse.org/r/55262 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=77bc07a3de5409bc00af7ef6277a7a5083645b51
Gerrit change https://git.eclipse.org/r/55273 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=e73cdf9d95e2a524a212c6a4ddcef4957b61f061
New Gerrit change created: https://git.eclipse.org/r/55348
New Gerrit change created: https://git.eclipse.org/r/55470
Gerrit change https://git.eclipse.org/r/55470 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=5fcbd2516470a98037852e898bc09bef80d93a9d
Gerrit change https://git.eclipse.org/r/55348 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=cfe127b3ca7b513eeb5d304a006e4faba249fbea
Should the removal of these bundles be announced, such as on "cross-project list"? I've already gotten one query about it, and not sure how many other projects may "pre-req" it? What changes might other projects have to do to migrate off of it?
It was announced with luna http://help.eclipse.org/luna/topic/org.eclipse.platform.doc.isv/porting/removals.html?cp=2_3_0#runtime that this would happen, also in the mars docs. Will talk to Sopot and have it announced on cross project for even broader audience.
(In reply to Alexander Kurtakov from comment #111) > Will talk to Sopot and have > it announced on cross project for even broader audience. +1
(In reply to Dani Megert from comment #112) > (In reply to Alexander Kurtakov from comment #111) > > Will talk to Sopot and have > > it announced on cross project for even broader audience. > > +1 Done.
New Gerrit change created: https://git.eclipse.org/r/55724
Gerrit change https://git.eclipse.org/r/55724 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=6d28e3872bae3066d1c0e4ef05c5ed34002830b0
AFAIK this can be marked as fixed.
