Community
Participate
Working Groups
The flexible hierarchy framework that is used to implement debugger views is currently provisional. This means that technically the backward compatibility of these APIs is not guaranteed between minor releases. The interfaces in question are found in the following packages in org.eclipse.debug.ui plugin: - org.eclipse.debug.internal.ui.viewers.model.provisional - org.eclipse.debug.internal.ui.breakpoints.provisional The Debug Platform team is committed to maintaining these APIs as if they were public. However, since they were initially created in packages that have ".internal.provisional" in their names, they cannot be made public since the API tooling facilities wouldn't recognize them as such. For more detailed discussions see bug 161435.
To better control/know your clients they should announce themselves to you. That way you can add them as friends so that they don't get warnings when using those provisional APIs.
Off the top of my head we should x-friend JSDT debug (CDT is already x-friended).
(In reply to comment #2) > Off the top of my head we should x-friend JSDT debug (CDT is already > x-friended). I cleaned up some of the x-friending in bug 368202
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
+1 for releasing the packages as API
Johan, can we move the packages out of the "provisional" space before the release as API?
(In reply to Lars Vogel from comment #6) > Johan, can we move the packages out of the "provisional" space before the > release as API? We could, but that would break CDT/JDT and lots of downstream consumers of the API. It is also likely to be more work than I am willing to take on at the moment. A warning has always been there - for example from https://help.eclipse.org/2021-03/topic/org.eclipse.cdt.doc.isv/guide/dsf/intro/dsf_programming_intro.html?cp=15_0_6 Note: Flexible Hierarchy is still a provisional API in Eclipse Platform 3.4. This virtually guarantees that DSF will break backward API compatibility in future releases. However, these APIs have now been widely used by open source projects such as DD and CDT and also by many commercial Eclipse integrations, so the API changes are likely to be small and mostly related to packaging. *BTW Jonah not Johan :-)
(In reply to Lars Vogel from comment #6) > Johan, can we move the packages out of the "provisional" space before the > release as API? Please check comments on bug 161435. I don't think changing the namespace is an option, the "non-API" in question is widely used. (In reply to Lars Vogel from comment #5) > +1 for releasing the packages as API Once released as API we *guarantee* that that API isn't broken on next release. Without PDE API tooling working no one can guarantee that. => -1 as long as we haven't verified if PDE can report API breakage for API placed in "internal" packages, see bug 161435 comment 27.
I agree that it is going to be difficult to move the types out of the internal provisional package namespace at this point. Something that will cause more harm than good at this point. I don't recall what the issue is with why API tools is not considering packages with the ".internal." segment. I would have assumed any package that is not mared x-internal or x-friends would have been processed by API tools regardless of the actual package name. For the future, any time a "provisional" package is being proposed we should try as much as possible to place that package in a namespace that we think could be its final graduating package name. Otherwise it only makes early adopters to feel pain for no reason once the API is ready to become final.
We cannot change the namespace for sure. @Vikas, Can you comment on the PDE part?
(In reply to Sarika Sinha from comment #10) > We cannot change the namespace for sure. > > @Vikas, > Can you comment on the PDE part? I will investigate tomorrow.
(In reply to Vikas Chandra from comment #11) > (In reply to Sarika Sinha from comment #10) > > We cannot change the namespace for sure. > > > > @Vikas, > > Can you comment on the PDE part? > > I will investigate tomorrow. Hi Vikas, did you have a chance to investigate this?
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.debug/+/181969
(In reply to Jonah Graham from comment #12) > (In reply to Vikas Chandra from comment #11) > > (In reply to Sarika Sinha from comment #10) > > > We cannot change the namespace for sure. > > > > > > @Vikas, > > > Can you comment on the PDE part? > > > > I will investigate tomorrow. > > Hi Vikas, did you have a chance to investigate this? IPackageDescriptor pkgDesc = Factory.packageDescriptor(pkgName); if (internal) { apiDesc.setVisibility(pkgDesc, VisibilityModifiers.PRIVATE); } if (friends != null) { apiDesc.setVisibility(pkgDesc, VisibilityModifiers.PRIVATE); //HERE !!!!! for (String friend : friends) { // annotate the api description for x-friends access levels apiDesc.setAccessLevel(Factory.componentDescriptor(friend), Factory.packageDescriptor(pkgName), IApiAccess.FRIEND); } } if (!internal && friends == null) { // there could have been directives that have nothing to do with // visibility, so we need to add the package as API in that case apiDesc.setVisibility(pkgDesc, VisibilityModifiers.API); } } This code suggests that the package is marked as private if there are some friends of an exported package. As such marking the package name *internal* or *provisional* or both still is considered as APIs from PDE API tools perspective.
At this point, I am not sure if just removing friends is good enough or if some things needs to be changed in api descriptor in the baseline too. I am investigating this.
Created attachment 286598 [details] packaged which has internal as a segment
Created attachment 286599 [details] Just changing the option from provisional API to public API should suffice Then the only thing to consider is whether we want to keep the same since tag as originally put or change to current version since tag. If we want to keep the original since tag, then we need to add API filter to the invalid API tag issue. If we want to update the version, we need to change the version first and then correct all invalid since tags.
(In reply to Vikas Chandra from comment #17) > Created attachment 286599 [details] > Just changing the option from provisional API to public API should suffice Great! > Then the only thing to consider is whether we want to keep the same since > tag as originally put or change to current version since tag. I would slightly prefer the since tag being since it was public API - this is the context of Bug 570692. Although we know that the API is probably the same since many versions, the tooling only guarantees it since it is marked public, so consumers should ideally have their minimum version set to the API being public or take on the risk themselves that they are depending on non-public API.
