More unanswered questions from the grey API thread, in addition to the ones I’ve posted just above this, as well as related issues stemming from recent WRM changes:
-
With the removal of
com.atlassian.crowd.embedded.*, how would Atlassian recommend that vendors reimplement substring searches needed for user/group pickers? I provided the existing, shipping code in an earlier post, but these APIs are being removed. -
The other problem I mentioned earlier in the grey API thread regarding the withdrawal of
WebResourceDataProviderhas only gotten worse in 8.8.0-beta1. Not only is that interface still deprecated, but now so are also all of the related public types for web-related module descriptors, includingWebItemModuleDescriptorandWebPanelModuleDescriptor. I see that various WRM methods are now marked as deprecated too, including:QueryParams,UrlReadingCondition,UrlBuilder, …, ad infinitum.
Adding insult to injury is that the latest EAP sources are still not readily available, so vendors can’t even see what the new @Deprecated annotations intend to reference as replacements, or when the deprecation was introduced or if it is marked for removal, leaving everyone guessing. At this point, vendors have to assume that every deprecated warning seen on the Confluence 8.8 build represents something that will be removed in 9.0.
For #2, I infer from a symbol search that the non-deprecated version of com.atlassian.plugin.web.descriptors.WebItemModuleDescriptor has now become com.atlassian.plugin.web.api.descriptors.WebItemModuleDescriptor, and that the WRM methods are being moved to a new “.spi” package.
The module descriptor interfaces are public APIs (not just de-facto APIs, but actual, documented and recommended APIs) that have been in use since Confluence 2.x and they are used by essentially every Confluence app!
For heaven’s sake, if the module descriptor types or WRM types need to be split into API and non-API packages (or SPI and non-SPI), please leave the publicly-used package names alone (ie. rename them back and un-deprecate them) and throw all of the non-API stuff you want to hide into a new “.impl” package (or whatever), and do whatever you want with the latter.
It otherwise becomes extremely difficult to ship a cross-version compatible app, unless you can guarantee a deprecation period of two years (to align with the oldest versions of Confluence that are still supported by Atlassian, and thus used by our mutual customers).
I see that the WRM part of the project is still being worked on ([PLUGWEB-694] - Ecosystem Jira) and I hope that some direction adjustment is possible.