A Confluence 8.8 EAP milestone is available now! EAP releases provide a snapshot of our work-in-progress and give you an opportunity to test and fix your apps before the final release.
As usual, we’ll be releasing weekly milestones and betas during the development of Confluence 8.8, so head to Preparing for Confluence 8.8 to find out what’s changed.
If you have any problems with an EAP release, please raise an issue to let us know. The earlier we know about problems, the more time we’ll have to fix them before the final release.
Enjoy!
The Atlassian Confluence team
We now announce Confluence Data Center releases in the Atlassian developer changelog. Subscribe to the changelog to receive the latest updates.
Thanks for the updates. There were a number of questions posted on the 8.7 beta thread (starting with post #10, Confluence 8.7 beta is available now - #10 by AndreasEbert) which have not been answered and which are still relevant as they relate to 9.0. Would it be possible to find someone to look at those (either here or there)?
Hi @Wendy ,
I tried the EAP 2.0 and I noticed that on the Manage apps screen the “Upload app” option is missing.
Is it intentional, and if it is, where can I upload custom apps?
Hi Anna (from a different Wendy, and yes, we’re both really Wendys).
I’ve updated our Preparing for 8.8 page with details of what’s changed. See the section with the title, ‘Changes to app uploads via the Universal Plugin Manager’, for further info. Apologies we hadn’t included this earlier.
I’ve updated our Preparing for 8.8 page with details of what’s changed. See the section with the title, ‘Changes to app uploads via the Universal Plugin Manager’, for further info. Apologies we hadn’t included this earlier.
A concern raised elsewhere by @oliver.straesser was that, with this new UPM change, customers will be unable to roll back to previous versions of Marketplace apps (even ones published on the Marketplace) in the case where a bug is present in the most recent version of the app.
Can you ask the development team how Atlassian plans to accommodate this? Large organizations require rollback capability as part of their change management process, and suggesting that customers need to restart the application to achieve this is a non-starter.
Also, this is being positioned as “to enhance security”, but this seems more like security theatre that comes at the expense of standard devops procedures, annoying customers and vendors alike. With the new changes, I can still install any Marketplace app…and if any single one of those Marketplace apps has the ability to run arbitrary code (for example, ScriptRunner), then you are no better off than before.
Repeating a question I previously posted in the 8.7 thread that has not been addressed. I see that this is now broken in 8.8.0-beta1 (not just in 9.0). I assume that 8.8 is shipping to customers next week, so the question becomes even more urgent.
How would Atlassian suggest that apps remain compatible with Confluence DC read-only mode, when the only Atlassian-suggested method for handling read-only mode has been removed and ServiceExceptionManager is no longer accessible?
[…] I see that the confluence-rest-api package has also been withdrawn. Apps need to use the ServiceExceptionManager interface contained within, as indicated by the Atlassian tutorial for making apps compatible with read-only mode .
While on the subject, the public UserAccessor#isDeactivated method was deprecated late in the 7.x series, with a suggested replacement of DisabledUserManager#isDisabled. But the DisabledUserManager bean does not seem to be accessible to plugins.
Trying to import the interface directly does not work, and neither does trying to do a named import of disabledUserChecker (which is what the actual bean seems to be named). Trying to import the underlying class CrowdDisabledUserManager also fails.
Am I doing something wrong, or is it possible that something needs to be addressed on the platform side?
Scott, thank you for so eloquently writing this down. We were just planning on immediately re-enabling the button, which seems like it would totally nuke any benefits to such a solution anyway.
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 WebResourceDataProvider has 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, including WebItemModuleDescriptor and WebPanelModuleDescriptor. 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.
I’m sorry I’m not responsible for this area of the code, but just like Wendy I’ll find the right people and get them to reply. I know from experience writing Apps within Atlassian that unfortunately Crowd APIs are often the only cross-product way to get what you need for this sort of use-case as SAL APIs are frankly under-developed. Of course, there’s always the product specific APIs.
Everything under com.atlassian.plugin.web and com.atlassian.plugin.webresource is my domain, feel free to always ping me WRT anything here.
There’s a lot here so let me break it down bit by bit;
com.atlassian.webresource.api.data.WebResourceDataProvider - the only thing that’s changing is it will extend from Java’s Supplier interface rather than Guava which is inline with removing third-party types from our API
WebItemModuleDescriptor, WebSectionModuleDescriptor, and WebPanelModuleDescriptor are all module descriptors for what we call web fragments. Nothing drastic is happening to them, they’re just moving to com.atlassian.plugin.web.api.descriptors so we can split the packages
Yes, as you’ve noted many of the WRM types are moving packages either into SPI or API and into the approriate modules.
I’m sorry, I can’t tell you why that is, I’ll pass on the message to the right team so they’re aware. To help in the meantime, there should be source jars on our public maven registry for all of the open source platform components we have. All the open source parts of the platform (which is most of it) is also public on Bitbucket, e.g. WRM, Web-Fragments.
Again, I’ll follow up with the source distribution, but please hold on for a couple of days before making any major decisions.
This is a such a broad generalisation which makes it - IMO - unfair, but I understand why you’re scared. Let me address that in the points below.
I understand that, allow me to speak within scope for the UI Platform components. It is not our intention to reduce the power you have to build apps, nor to create work we don’t think is worth the trade-off. I have been very careful in my analysis in ensuring vendors always have a way to achieve what they need and keeping it as much the same as possible.
If there is anything you think you can no longer do after you read through the new sources related to the UI Platform; tell me. I want to know, I will do something about it to unblock you.
We need to break API in major versions so we can keep it stable otherwise. I know the pain of maintaining release branches, I’ve done it the whole time I’ve been here. In some projects we’ve had more than a dozen in active support. So I get why you want to avoid this, I’ve also engineered plugins that are cross-major-compatible for this reason. This isn’t supported though. You should ideally only ever need two release branches as a vendor with only 2 platform versions of our products being supported at any given time
In the case of the Web-Resource Manager (WRM) there are other changes to the interfaces we need to perform that mean there was no chance of cross-major-compatibility to begin with. Given that, we’ve decided to align for consistency and being able to enable various kinds of new testing on API and SPI (so we have even more confidence we’re not breaking apps).
The last two major versions of the WRM (which I was involved in) were for the most part backward compatible. The changes that aren’t package renames for the most part have been deprecated for 5-10 years and at minimum 2.
In the case of Web-Fragments we were able to keep com.atlassian.plugin.web public while moving implementation and we did it because we know WebInterfaceManager is used by hundreds of plugins to minimise work for everyone. However, for the much less used APIs we had to move them into the api subpackage.
WRM and Web-Fragments need to be modifiable to unblock all development on them otherwise they’re effectively frozen for two years which would corner us into make breaking changes in minors and bugfix versions for things like vulnerabilities. There are many issues with these modules and other improvements that rely on these modules’ internals being modifiable, I won’t go into further detail as it’d triple the length of this reply.
There are roughly a dozen more UI Platform components that are largely untouched and the chances are high Apps could be cross-major-compatible.
In case you’re not aware our products do support OBRs which can contain multiple plugins, there’s various ways of utilising that to be able to ship a single version of an App on Marketplace. Of course, it’s up to you to decide whether that cost and complexity is worth it instead of shipping two different versions of your App.
We have seen that you have incorporated to Confluence 8.7.2 the changes done for the section Removal of Velocity servlet support in Confluence for Confluence 8.8. This is breaking our apps as they are not rendering properly the vm’s.
Error:
Can you please provide a timeframe in which you are preparing to release Confluence 8.8?
Both me and @scott.dudley have been trying to get the Atlassian Marketplace Partner community to understand the importance of trying out this EAP given that it is intertwined with the grey API removal scheduled for Confluence 9.
I understand the importance of paving the way from a code base perspective, but from a Marketplace Partner perspective, the impact has been difficult to asses. It is also not helpful that the communications regarding grey API removal is somewhat scattered with multiple Confluence EAPs (8.7 and 8.8), a blog post and multipleCDACposts.
It feels like all the time we have to push back on this as a result of our findings is limited to Confluence 8.8, which is already 16 days old and probably going to final stages of release, and yet most Marketplace Partners seems to be completely unaware that this is their final opportunity to speak up.
Given the possible impact this has on apps, it would be great if there would be a proper timeline for gathering feedback that allows partners ample opportunity to fully asses the impact and make sure that we have a release ready when Confluence 9 becomes GA.