Announcing Data Center Platform 7.0. Next step to improve our security posture

Announcements
, , , ,
21

Hi all,

A quick update - there was an error in Confluence 8.7 where the com.aatlassian.crowd.embedded.api package got wrongly moved to the deprecated list. We’re addressing this in the next 8.7 bugfix (if there is one), and it’ll be resolved in Confluence 8.8 as well.

As part of the upcoming changes, embedded-crowd-spi and embedded-crowd-core are set to be removed from the public API, while embedded-crowd-api will stay unaffected. Here’s an initial list of packages that may be available. However, the final list of packages will be shared in approximately 2-3 weeks -

  • com.atlassian.crowd.embedded.api
  • com.atlassian.crowd.embedded.impl
  • com.atlassian.crowd.exception
  • com.atlassian.crowd.exception.crypto
  • com.atlassian.crowd.exception.embedded
  • com.atlassian.crowd.exception.runtime
  • com.atlassian.crowd.validator

On a different note, please be aware that Java 17 will become the minimum supported version of Java in “Platform 7”. Every component should be compiled and tested on Java 17. It will enable using Java 17 features in our codebase. This means we are dropping the support for Java 8 and 11 in all our major releases (Jira 10, Confluence 9, Bitbucket 9, Crowd 6 and Bamboo 10 )

5 Likes
22

Hi @MalathiVangalapati

This means that we will have to target our projects in Java 8/11 and Java 17 to be compatible with clients on Jira 10 as well as those on Jira 9.12 (the current latest LTS).

So, will we have to deliver two versions of our apps?

Thanks
Fabien

23

You can compile with Java 17 but keep the language level set to Java 8. Thus, this will create byte code that runs with Java 8 but was compiled with Java 17.

24

Hi @FabienPenchenat

Based on the number of changes in API I would recommend supporting 2 versions anyway. This is also the approach we have in our own components (plugins).

1 Like
25

Hi @chrschommer

Writing code on Java 8 level is limiting us. By setting language level to 17 we are enabling new possibilities in our code. We also observe increasing number of libraries compiling with Java 17 (language level), that may be a serious limitation in the future support (as we will be supporting Platform 7 for 2+ years).

We understand it can have an impact on your environment, but we need to move faster if we want to catch-up with the industry.

1 Like
26

Hi @clouless

On the high level we are moving to JAX-RS 2 and we are limiting our own API:

  • there is no direct access to the engine (Jersey 1 in case of current versions)
  • there is no direct access to the “Atlassian REST” internals
  • anything considered API is moved to a single package and Maven module

The scope of changes for “Atlassian REST” consumers will vary between usages.

From our experience JAX-RS 1 and 2 are pretty similar in the basics. If your plugin relies only on that (e.g. Path, @GET etc.) your update may be limited to the dependency change in Maven.

There will be some changes around Filters and binding, as we will use JAX-RS native API. The same applies to parts of our API. Our main goal is to provide the same or similar set of functionalities that is used currently in the plugins.

Please have in mind I mentioned only high level changes. We will publish a guide for migration in the following weeks.

3 Likes
27

Yep, I get your point :grinning:. We compile against Java 17, but with language level on 8. I would love to use new Java features, like Map.of or the “var” keyword. But with supporting older versions, we can think about moving to a new language level in a couple of years :grimacing:

28

How will the deliveries on the marketplace work then if we 2 same versions but compiled with different Java version for different LTS ?

2 Likes
29

Hi @MarekTokarski ,
thanks for the outline. Then if proper docs are provided how to change the maven dependencies, it will be manageable :slight_smile:

I am using basically only the “standard” annotations like:

import javax.ws.rs.Consumes;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.QueryParam;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.Response;

@Path("/download_list/")
@Component
public class DownloadListEndpoint extends BaseEndpoint {
...
    @GET
    @Path("/xml")
    @Consumes({MediaType.APPLICATION_XML})
    @Produces({MediaType.APPLICATION_XML})
    @AnonymousAllowed
    public Response xmlList(
        @QueryParam("contentId") Long contentId,
        @QueryParam("macroId") String macroId_raw
    ) {
...
                return Response.ok(listModel.toXML()).build();

So I hope not much to do regarding the migration :slight_smile:

30

I’m just going to leave this here :sunglasses:

1 Like
31

This is an easy thing to say, however it is not customer centric and is a huge burden on all app vendors, the impacts of which then trickle down to customers. I’ve seen a couple of replies along the lines of “just ship two versions”, with little to no commentary from Atlassian about why a vendor would not want to do that.

The sentiment being expressed is you will certainly need two versions of the app, however I’m sure there is nuance and workarounds that could be put in place by vendors to avoid this. The information about how to do this however is somewhat siloed, if possible I’ll try to document what we’re doing here at team ScriptRunner.

Personally if I have to spend a month engineering the app to be cross version compatible, I would gladly take that hit on productivity in the short term, because I have seen the business and customer impact of the alternative.

Customers on older platform versions have paid Atlassian (and us as the vendor) and rightfully expect to receive consistent updates, as long as their host application version is not end of life.

With the host application there is no expectation of new features without upgrading the major/minor version, however with apps there is more of an expectation of consistent updates. Some vendors make the choice to only fix bugs and security issues on older application versions, others opt to ship as much new functionality as is financially viable to all supported versions.

I accept that a major release is the only opportunity Atlassian has to properly introduce breaking changes, and have no issue with that in isolation. I do have an issue with statements that make it seem like forking your app codebase is a trivial endeavour, and that it does not f*ck the customer.

Atlassian’s job here is to clearly document all planned breaking changes, which has not yet happened, so app vendors can work with their teams to put together a backlog of work. The end goal being Platform 7 compatible on day 0, or as close to it as is possible.

15 Likes
32

I would suggest additional tooling in Atlassian Marketplace to handle this dual nature of plugins developed on Data Center Platform 7.0 and backwards compatibility.
We would like to support customers on LTS versions of products but also the latest and there will be a time when the latest release of our plugin will need multiple update channels.
Can you please establish a Data Center Platform 7.0 update channel so we can upload separate jar files with compatibility for latest versions of host products in a way that we don’t receive hundreds of compatibility requests from older customers because the latest version (build for Data Center Platform 7.0) doesn’t support their host.
With multiple update channels the Data Center Platform 7.0 jars should not be visible to the earlier products in UPM so there is no confusion on which version is actually the latest, 2.0.0 or 2.0.0-pre-platform-7, since we would probably have to create those tagged versions for backwards compatibility if no measures from Atlassian Marketplace and UPM are implemented.

2 Likes
33

Hi, I didn’t look into UPM code in a while, but from what I remember Atlassian Marketplace allows you to set compatibility range for any version of a plugin you upload. UPM will recommend update to the instance administrator, only if there is a new version compatible with the host product version.

Is there anything else you would like to see?

34

Well if there is a newer upload and the plugin is not in the supported range will it not offer to submit “A user requested a compatibility update” notice to the developer?
Our plan was to upload 2 versions, one for backwards compatibility and one for Data Center Platform 7.0, but I find it a bit of a dirty since depending on the order of uploads, each user group may request compatibility. That’s why I was suggesting for a separate update channel for specific versions, maybe adding a new field in the Marketplace upload API that could add this, like platformCompatibility: 7.0, then it wouldn’t be suggested to sub 7.0

When it comes to other issues, any tooling like mvn inspection in the SDK or an Intellij Plugin with inspections and refactorings that could help flag or even quick fix some of the obvious issues that everyone will be facing.

1 Like
35

In the attached pdf there are entries like:

com.atlassian.plugins:atlassian-plugins-webfragment
or
com.atlassian.plugins:atlassian-plugins-webresource
which are marked as “none”

What does it mean? Removal?
And what should we do if we use these packages via osgi import?

36

My bad for causing confusion there, I can see now the wording is ambiguous. When there is “none” in the column, it means we don’t have a milestone yet containing all the deprecations we announced. Rest assured that we are not removing those packages. We’re currently prioritising getting milestone versions ready for you to experiment with. I expect us to finish the last milestones by the end of February the very latest, but we’ll be releasing things as they become ready.

We also expect these versions to be integrated into upcoming EAPs, but the changes we’ve made also need some time to adopt into the different products, which is why there may be a delay there.

2 Likes
37

OK and what about JS changes.

In the console I can see:

Use of window._ through AUI is deprecated and will be removed in AUI 10.0.0

Use of window.Backbone through AUI is deprecated and will be removed in AUI 10.0.0

DEPRECATED JS - JQuery.fn.spinStop has been deprecated since 7.9.4 and will be removed in 10.0.0. Use instead.

DEPRECATED undefined - AJS.params has been deprecated since 9.0.0 and will be removed in 10.0.0.

DEPRECATED JS - PopulateParameters has been deprecated since 9.0.0 and will be removed in 10.0.0.

DEPRECATED JS - Inline dialog constructor has been deprecated and will be removed in a future release. Use inline dialog 2 instead.

So do you plan to change frontend implementation technology, structure, or something?
Any plans to migrate boards or issue search navigator to react or new components?

5 Likes
38

Can you please add tooling to the AMPS project to easily be able to build for Data Center Platform 7.0 like adjustment in the banned dependency list?
Would be great if there was at least a branch and a tagged release we can already use to test:
https://bitbucket.org/atlassian/amps/branches/

3 Likes
39

I have attempted at running our plugin in Confluence 9 docker (atlassian/confluence:9.0.0-m08-jdk17) and after multiple dependency errors with OSGI fixed, I landed on a problem with the scanner:

org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.atlassian.com/schema/atlassian-scanner/2]
Offending resource: URL [bundle://84c5856c-5418-498f-8fda-db8b6ddc4ef2_311.0:0/META-INF/spring/spring-context.xml]

Could you please provide an open source example plugin that uses com.atlassian.crowd.embedded (and other affected dependencies) before platform 7 and after upgrade? A full maven project that will give us an illustration of all the changes that need to happen?

3 Likes
40

@KsaweryBuczkowski, in case your talking about com.atlassian.crowd.embedded.api, see this detail of Malathi’s post above: