Confluence 7.0 EAP released

Hi everyone,

The first Confluence 7.0 EAP milestone is now available. 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.

Confluence 7.0 is a platform release, so it will contain breaking changes including:

Java 11 support

We’re adding support for Java 11 in Confluence 7.0. We’re currently working on runtime compatibility, and hope to also be able to provide compile compatibility. As with Java 8, we’ll continue to support both Oracle and AdoptOpenJDK.

Removing deprecated code

We’re currently working to remove all code paths deprecated in Confluence 5.x and earlier. Changes like this help us maintain a healthy code-base, remove hurdles for developers, and simplify the code structure where possible. See our Deprecated code paths removed in 7.0 page for the list of classes and methods removed.

Feature deprecations

We plan to deprecate or remove a small number of features in Confluence 7.0, including some macros and gadgets.

As usual, we’ll be releasing weekly milestones and betas during the development of 7.0. We’ve extended our release timeline, so expect some additional EAPs before the final release. Head to Preparing for Confluence 7.0 to read more about our planned changes, and to find out what’s changed in this milestone.

Get the latest EAP

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!

3 Likes

Hi @mmortimer,

is there any statement about deprecated APIs in bundled plugins and libraries? I’m mostly concerned about the webresources plugin and trustedapps library. We use some deprecated APIs from those where we could not find a suitable replacement.

We also use the ConfluenceRpc and related classes from the confluence-test-support library extensively in our integration tests. Is there any information whether this will be ported to REST APIs by the Confluence team so it can be used in the future? Given that XML RPC APIs are supposed to be removed in 7.0 I take it this will cease to work unless it is ported to newer APIs.
We are currently estimating the effort to migrate our required feature subset of it to REST APIs ourselves. Since this will be a lot of effort it would be great to know about Atlassian’s plans for it in advance. I’ve seen that the deprecated classes from this library are still used in Confluence’s tests as well (in yesterday’s milestone 05) so I guess there are some plans for it.

Thanks!
Jens

3 Likes

@mmortimer While on the topic of deprecations, are there any plans to introduce replacements for the deprecated GeneralUtil class (particularly GeneralUtil#htmlEncode and GeneralUtil#urlEncode) by exposing the new HtmlUtil within the default Velocity context?

I understand that these were only deprecated in 6.10 and won’t be removed in this round. However, when it does come time to remove the GeneralUtil methods (in 8.0?), it will make the lives of third-party devs much easier if the replacements were already made available at the time of the start of the deprecation.

Scott

2 Likes

Hei hei @jens

When it comes to Confluence XML RPC APIs, we are not removing them from 7.0 because we have not ported all of them to REST yet, which is why the deprecated test classes are still in use.
I would recommend to start migrating your integration tests to rely on as much REST APIs as possible, you may follow the examples available here https://bitbucket.org/viqueen/confluence-community/src/master/src/test/java/it/com/atlassian/confluence/community/ConfluenceCommunityRestStatelessTest.java

3 Likes

Hei hei @scott.dudley

The HtmlUtil class is indeed exposed already in the velocity context and you may access its methods as follow $htmlUtil.urlEncode()

Thank you for bringing it up, we will make sure to update our developer docs

1 Like

Hi @viqueen, thanks for preparing that example :slight_smile:

I already found the remote clients in the confluence-rest-client maven module earlier but was a bit uncertain concerning their relation to confluence-test-utils because of the comment in ConfluenceRestClient.
Since the confluence-stateless-test-runner library you use in your example also uses ConfluenceRestClient from confluence-test-utils internally I suppose this one is safe to use as sort of an aggregator / entry point for the individual REST API client classes.

Am I getting this right?

The stuff in confluence-stateless-test-runner looks very interesting but we won’t switch to it mid-term because of the way our existing tests are structured and how they set up their fixtures. Migrating would mean a major refactoring / rewrite of our test cases.

Thanks,
Jens

That is correct , confluence-stateless-test-runner and ConfluenceRestClient from confluence-test-utils are safe to use; this is what our teams are migrating to and using internally.

I totally agree it is a bit of a refactor / rewrite, but that is an exercise our team needed to go through.

Please do reach out with more questions.

Thanks !
Hasnae

2 Likes

Hi @viqueen, thanks for confirming!

I actually do have more questions :slight_smile:

Is there any statement about deprecated APIs in bundled plugins and libraries? More specifically:

  • Will you remove trusted apps in Confluence 7? We need this for authentication of requests from the server to itself (required for downloading dynamically created content in our exporters).
  • Will you update the webresource plugin to a version where com.atlassian.plugin.webresource.assembler.LegacyPageBuilderService#clearRequestLocal no longer exists? We use this API when performing multi-page exports in one thread to avoid spurious entries in the web resources.
  • Will you remove the deprecated constructors in the search related classes for 7.0? The replacement constructors sometimes require managers that are not exposed to the plugin system. One example for this would be com.atlassian.confluence.search.v2.searchfilter.SiteSearchPermissionsSearchFilter. In general the replacement constructor only really seem to be required when using some elastic search related dark features. I’ve seen the announcement that the search subsystem will see more updates in the future, so I was wondering if you will apply these API changes already now with 7.0.

Thanks!
Jens

Hei hei @jens

More questions are very welcome !
Thanks
Hasnae

Hey @viqueen,

Do you or the team have any updates on the Lucene deprecation. We’re really interested in what alternatives will be made available?

Thanks,
Dylan

Hey @dlindsay, thanks for the question. I’ve passed this onto the team – we’ll get back to you soon.

Hu @dlindsay, Lucene API is deprecated in 7.0 and will be eventually removed from Confluence. There is substitution for it. Specifically on the indexing side, Extractor API will be replaced by Extractor2 API which is Lucene agnostic and enhanced to support text analyzer whilst the index recovery module will be removed without substitution.

On the query side, w.r.t. low level query the V2 Query extension will be replaced by using V2 Query expansion mechanism in combination with newly added V2 Query primitives. Boosting strategy will be replaced by newly added Function score query. There is no change to high level query aka CQL search, it is already Lucene agnostic.

Please let us know if you need anything more.

Hi @mmortimer and @huyle,

We really appreciate the detailed response! Just to clarify, will the indexing and query changes be available from Confluence 7.0 or is this planned to be added at a later date?

All the best,
Dylan

They will be available from Confluence 7.0.

best regards

Huy

Excellent, many thanks!

Hi all,
First of all, thank you for the detailed preparation documentation related to 7.0. I was just wondering if there’s a rough timeline for when the version will be released so that we can plan accordingly.

Best regards,
Dennis

Hi @rw-dennis, thanks for your question. As a platform release, the development schedule for 7.0 is longer than our usual 7 weeks. We’ll be releasing additional EAP milestones, plus at least two betas and a release candidate, so you’ll have some time to prepare before the final release :slight_smile:. Hope this helps!

Can you please provide more information about what will and won’t be available in future in regards to lucene and what the replacements are going to be?

We make extensive use of things like Lucene Query Mapper and Sorting plugin modules. We also use direct lucene API things like luceneConnection to perform searches for content in a performance acceptable way.

Hi Shannon, direct access to Lucene connection is deprecated as well as Lucene query/filter/sort mapper. The v2 search api (accessible through SearchManager, SearchQuery, SearchSort) will be extended and improved in term of performance to cover most typical use cases so in general there will be reasonable substitution for the deprecated API. Within Atlassian we will also migrate all our Confluence plugins to get rid of direct access to Lucene to make sure that the substitution is viable for vendors.
If you have difficulties, we will assist you what is the best way to replace existing Lucene API by an equivalence.

Hi!
We also make use of quite a lot Lucene specific functionality. I tried to implement one of our apps with Confluence 7 m60 and without using any deprecated code, and have a few questions regards the search changes.

  1. Instead of using a LuceneQueryMapper returning lucene..TermQuery we should just use v2..TermQuery?

  2. Some of our Lucene Query Mappers return lucene.search.WildcardQuery, and I did not find a substitute yet that would pass our tests. I would assume that v2.query.TextFieldQuery would be the correct way to go, but it does not seem to provide the same results. Is there a migration available in Confluence 7 m60?

  3. We are also using some org.apache.lucene -classes directly to provide highlighting of search results in our UI. I assume that since Confluence 6 we should be able to achieve this in Lucene-agnostic way by SearchResult.get***WithHighlights() methods?

  4. We use Boosting strategy to hide certain items in some Confluence spaces regardless of the query used. This should be in effect also when the user is using the default Confluence search. Will this use case be supported by the ‘score query’ Function?