Community
Participate
Working Groups
The WorkspaceLock API allowed a special client (usually platform UI) to hook into the locking protocols used by the workspace implementation. This hook was used to mitigate deadlocks due to interaction with synchronous SWT events, and was never intended to be used by other clients. In the 3.0 release this API was deprecated in favor of a more general API provided by the org.eclipse.core.jobs bundle. Invoking this API has had no effect since the 3.0 release. Any client still referencing this API most certainly has a bug in their code, because the API no longer has any effect. The specific API to be removed includes: classes: org.eclipse.core.resources.WorkspaceLock methods: org.eclipse.core.resources.IWorkspace#setWorkspaceLock
Related links: http://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process http://wiki.eclipse.org/Eclipse/API_Central/Deprecation_Policy
Makes sense to remove it. The current situation is that client code can be unknowingly busted; removing it will force any such consumers to update their plug-ins. Hopefully, no significant zombie plug-ins (i.e. old ones that are still being used but no longer developed) will be impacted.
Does it make sense to have a keyword to mark such reports? We already have two in Resources and probably others will be raised.
(In reply to comment #3) > Does it make sense to have a keyword to mark such reports? We already have two > in Resources and probably others will be raised. I added the API keyword, but the main list of such bugs should appear in the API removals section of the porting guide in org.eclipse.platform.doc.isv. Which is the other bug?
(In reply to comment #4) > Which is the other bug? Bug 310072.
I have released a comment in the javadoc notifying about the pending deletion and referencing this bug.
Targeting for M5 before it is too late to make any API changes.
Created attachment 238450 [details] Patch
Go ahead when you are ready Szymon. Make sure bundle minor version is incremented for Luna if it is not already.
Thanks! Fixed in master: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=ade195fee4ef7991618e5b7bb6804bad885bca37
The documentation (migration guide, api removals) needs to be updated.
Please set the correct API Baseline (4.3.1, see [1]) in your workspace and then create compatibility problem filters for the removed APIs. [1] https://wiki.eclipse.org/Version_Numbering#API_Baseline_in_API_Tools
(In reply to Markus Keller from comment #12) > Please set the correct API Baseline (4.3.1, see [1]) in your workspace and > then create compatibility problem filters for the removed APIs. > > [1] https://wiki.eclipse.org/Version_Numbering#API_Baseline_in_API_Tools Thanks! Fixed in master: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=edec9a10d364672000cf2c4944df1be998728271
Created attachment 238747 [details] Documentation update (In reply to Dani Megert from comment #11) > The documentation (migration guide, api removals) needs to be updated. Dani, could you please review documentation updates?
(In reply to Szymon Ptaszkiewicz from comment #14) > Created attachment 238747 [details] [diff] > Documentation update > > (In reply to Dani Megert from comment #11) > > The documentation (migration guide, api removals) needs to be updated. > > Dani, could you please review documentation updates? Given the API is removed, it should be mentioned in the "incompatibilities" document, along with how to fix the incompatibility. > "API removals in the Luna (4.4) release:" I would make it even more explicit: Removed APIs in the Luna (4.4) release: Make sure the copyright dates are correct.
(In reply to Dani Megert from comment #15) Thanks! Fixed in master: http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=79280fdcc203876a574be98076882497bea53a6c
Just to cross-reference any impacts, bug 426471 mentions one "breakage" in a JSF test plugin. (And, to be explicit, I'm just documenting it, not implying anything else).
(In reply to John Arthorne from comment #9) > Go ahead when you are ready Szymon. Make sure bundle minor version is > incremented for Luna if it is not already. I'm surprised by this API removal in a minor release. Is that really "allowed" by the good policies? The reason I ask is that several of my own bundles re-export core.resources because their APIs use IResource in their signatures. Now, all of a sudden, API Tools ask me to increase my major versions because of the breakage introduced by the removal of this deprecated API class WorkspaceLock. Please note note that I don't deal with this class directly. If the use of this deprecated class causes problems at runtime wouldn't it be less invasive to "non-users" like me to just throw UnsupportedOperationExceptions (in addition to the existing deprecation warnings) from all methods?
(In reply to Eike Stepper from comment #18) > > I'm surprised by this API removal in a minor release. Is that really > "allowed" by the good policies? This does imply that the major version should go up, but I thought it's also at the discretion of the PMC. http://wiki.eclipse.org/Eclipse/API_Central/Deprecation_Policy#Bundle_and_Package_Versions > > The reason I ask is that several of my own bundles re-export core.resources > because their APIs use IResource in their signatures. Now, all of a sudden, > API Tools ask me to increase my major versions because of the breakage > introduced by the removal of this deprecated API class WorkspaceLock. The best practice is not to re-export other bundles, and let the consumers include those bundles themselves (gives them an accurate picture of what they're using). That being said (we have bundles in platform that re-export other bundles' API), if you do re-export a bundles API you are then tied to their API. If they increase it, you must increase yours (because your API footprint will have changed). PW
(In reply to Paul Webster from comment #19) > (In reply to Eike Stepper from comment #18) > > > > I'm surprised by this API removal in a minor release. Is that really > > "allowed" by the good policies? > > This does imply that the major version should go up, but I thought it's also > at the discretion of the PMC. > http://wiki.eclipse.org/Eclipse/API_Central/ > Deprecation_Policy#Bundle_and_Package_Versions To me that paragraph seems to be clear that in all cases of API removal the major version must go up: "As described in the Version Numbering guidelines, removal of any API is a breaking change, so the major version of bundles and packages exporting the API must increment their major version number and reset the minor and service numbers to zero." A preceding paragraph says that API may only be removed at all with PMC approval, but not that the major version may be kept in that case. And to me that makes perfect sense. What are versions worth if they're no longer semantic, i.e. reflect the actual change? > > The reason I ask is that several of my own bundles re-export core.resources > > because their APIs use IResource in their signatures. Now, all of a sudden, > > API Tools ask me to increase my major versions because of the breakage > > introduced by the removal of this deprecated API class WorkspaceLock. > > > The best practice is not to re-export other bundles, and let the consumers > include those bundles themselves (gives them an accurate picture of what > they're using). I do remember recurring discussions about this specific topic, but unfortunately no consensus. Personally I've always advocated that the usage of imported API in own API practically re-exports these imported APIs anyway and that it is not helpful for consumers if these imported bundles are not explicitely marked as re-exported. The effect of not re-exporting these needed bundles is that consumers have to transitively go through all dependencies and import them into their own bundle if they don't want to end in a sea of warnings that are hard to understand (can't remember the exact message text, something about required class files). > That being said (we have bundles in platform that re-export > other bundles' API), if you do re-export a bundles API you are then tied to > their API. If they increase it, you must increase yours (because your API > footprint will have changed). Correct. That is why I asked if it was really necessary to break the formal API of a bundle that is at the core of everything ;-)
(In reply to Eike Stepper from comment #18) > I'm surprised by this API removal in a minor release. There's not such thing as "minor" release. We have annual releases and then the two SRs, in which we'd not do such a removal of course. > Is that really "allowed" by the good policies? Yes, see https://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process The (future) removal was initially announced in 3.6 and was actually planned for 2012 back then. It's also listed in the 4.3 migration guide: http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fporting%2Fremovals.html&cp=2_3_0
(In reply to Dani Megert from comment #21) > (In reply to Eike Stepper from comment #18) > > I'm surprised by this API removal in a minor release. > > There's not such thing as "minor" release. We have annual releases and then > the two SRs, in which we'd not do such a removal of course. As I understand it, Eike's concern here was that removal process says core.resources version should go to 4.0.0 but we only bumped the minor version. PW
(In reply to Eike Stepper from comment #20) > > I do remember recurring discussions about this specific topic, but > unfortunately no consensus. OSGi describes the best practice of always specifying bundles that you need to consume and not re-exporting API to avoid bundle coupling. That others have (valid) reasons for going another way just means they've decided not to follow the OSGi best practice and must consume the consequence ... any bump in a re-exported API automatically requires a bump in their API. > Correct. That is why I asked if it was really necessary to break the formal > API of a bundle that is at the core of everything ;-) They followed the process for removal of deprecated API. You'd have a similar error if they bumped the major version as suggested in the doc as well :-) PW
The last thing I ask for is to increase the major version! And actually I can live with the situation and add API problem filters where needed.
