Starting from 8.6.x, new releases of Confluence will be available only to Data Center customers. If you have a Server license, check out your options for upgrading.
Be aware that 8.6 also has subtle, undocumented(?) changes to how custom search indexing (via Lucene) is done. This broke two of our apps, i.e. many field-specific searches (of the form “${fieldName}:${searchTerm}”, e.g. “Skills:design” or “Location:Berlin”) did not find the expected results. We used to use com.atlassian.confluence.plugins.index.api.FieldDescriptor to index our fields.
After much analysis we found a working solution for us: Use TextFieldDescriptor instead of FieldDescriptor. With this, indexing – and therefore searching – works as expected again.
@Atlassian: We’re curious: What changed here? We found nothing in the public docs about this, and not even deep-diving into the related Lucene/search libraries and comparing 8.5’s code with 8.6’s code showed us what the actual cause/change is.
Although we did eventually find a fix for our apps, it’s somewhat unsatisfying to not know why that fix works, i.e. what the actual cause is.
Thanks for any insights.
The tests use ConfluenceStatelessTestRunner and I have seen some announcements about changes from Selenium 2 to Selenium 3 ( Selenium 3 upgrade guide | Confluence Data Center and Server 8.6 | Atlassian Documentation ) but this looks more like a dependency that used to be available but no longer is, maybe a transitive dependency that is not longer transitive?
I’m new to this plugin that has these tests and I’ve never used Confluence’s stateless test runner and my pom.xml looks nothing like the pom.xml on that “Selenium 2 → 3” guide so I could be missing something obvious, but I’m going to dig in now.
If anyone already knows the solution to this problem and can share you might spare me some pain.
We’re also using FieldDescriptor in some of our apps, but haven’t seen any problems so far. The main point of TextFieldDescriptor seems to be that it enforces Index.ANALYZED, which could be related to what you’ve been describing, @AndreasEbert
Our apps always use Index.NOT_ANALYZED, and I wonder if that makes a difference.
@Wendy I would be great if a developer could have a look at this.
Btw. it does NOT help that we can suddenly no longer download the source code of Confluence to see the deprecation notes.
We did indeed already use Index.ANALYZED before with FieldDescriptor. So, effectively the Index value stays on Index.ANALYZED in our app. That is one of the things that confuses as and what I meant with: “Although we did eventually find a fix for our apps, it’s somewhat unsatisfying to not know why that fix works, i.e. what the actual cause is.”
Concerning the source download not working: Same for us. We filed a support ticket with Atlassian and got the response, that source downloads are temporarily disabled due to security concerns ¯\_(ツ)_/¯
With the deprecation, could you suggest the correct replacement for VelocityUtils#getVelocityEngine()? This doesn’t seem to exist in VelocityHelperService.
I am getting a strange error doing altas debug builds with 8.6.0, I reference org.joda.time.DateTime class, which is used with your PluginLicense class (getCreationDate) returns this class.
However I get this error when compiling my code, this is new, I have had this code for 10+ years, why now can’t this compile. I can even go back to version 8.5.x and it works.
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.11.0:compile (default-compile) on project xxxxx: Compilation failure: Compilation failure:
[ERROR] /C:/Builds/common-tools/src/main/java/net/kentcom/common/LicenseCheck.java:[14,21] package org.joda.time does not exist
What is the reason for this? I can’t seem to get around this, other than remove my code!
Hi @DavidPasternak, I agree, it is confusing I’ve passed this feedback on to the team. I believe they’ll be making changes to this part of the site at a later date.
Are you able to determine what the non-deprecated replacement for this might be?
I also second the request of @michael.rueegg to see if there is any way to expedite access to the missing source downloads. We are currently trying to diagnose a complicated problem with a customer and the absence of Confluence sources is impacting our ability to troubleshoot the problem.