Platform 7 upgrade in progress: Learn about the first highlights and changes

Hi Developer Community :wave:,

We recognize there is a lack of clarity around some of the changes that will be shipped as part of future Atlassian Data Center products. In this post, we want to go into more detail on some of the changes that are shipped as part of Platform 7 and let you know what our next steps are to address the concerns brought up across several communication channels.

The Platform acts as a baseline of common libraries and plugins that are used across all products. Products like Jira and Confluence typically expose parts of this Platform as Java API. Since products need to integrate new versions of the Platform and then, deploy a new version, you may find that there are different versions of the Platform across products at any given time.

However, it is possible to get direct access to what is available in the Platform. In reality, the Platform is nothing more than a set of dependencies managed through Maven POM files in Platform Dependencies. For app developers, the most relevant are:

  • platform-public-api dependencies exported through OSGi and publicly available to all apps.
  • platform-deprecated-public-api dependencies that we will remove in the next major version of the Platform. Typically, a new major product version ships with a new major version of the Platform, and at least for the upcoming major versions of Data Center products, it is expected they will ship with Platform 7.

We regularly release Platform 7 milestones. These are primarily aimed at Atlassian Data Center products to aid in the early adoption of the changes. We recognize that for you – Marketplace partners and app developers – these early versions may also help in identifying the impact the changes will have on your own apps. While not a replacement for the documentation on all changes – we are working on it and it will get in your hands as soon as possible – comparing the POMs directly may give you an early indication of the changes we’ve made.

Our current focus is to finish the implementation phase, and towards the end of February, you should find the public API of the Platform to reach a stable state. Because the work on the Platform 7 release is still in progress, we are still expecting some minor changes. However, the current state of the public API is indicative of the final state, and we do not expect these changes to have a major impact on your migration. But if you want to play it safe: we expect to release the stable version of Platform 7 by early Q2 2024.

Platform 7 only covers the common aspects of each Atlassian Data Center product, and each product may individually make further changes to its own APIs or feature set. Covering all of those in this post would be too much, but as a rule of thumb, the next platform versions of each product will contain the changes as discussed in this post. Refer to the posts below for more product-specific information:

Platform 7 high-level changes

API changes

We have reduced the number of third-party libraries and improved the overall definition of our Java API. We have previously released a minor version of the Platform – version 6.5, containing the majority of deprecations and API changes. We plan for this to be the last minor release before Platform 7.0. Platform 6.5 allows for a transitional period for app developers. We expect new feature versions of Atlassian Data Center products containing these changes to be released – either in full or as an EAP – through the coming weeks. However, timelines vary for the different products.

With the exception of some modules (like Atlassian Plugins or Crowd), we have completed the work of removing the deprecated API. The next step we are working on right now is to integrate all of the different work streams together into the final set of Platform dependencies. As we adopt these changes, we regularly release milestones of the Platform Dependencies (at no particular cadence). These milestones are numbered using the 7.0.0-m## versions and are available through the Maven repository in case you want to inspect the changes early. Alternatively, the deprecations shipped with Platform 6.5 cover the majority of announced changes.

Atlassian REST v2

Due to how tightly coupled the implementation of Atlassian REST was with JAX-RS 1 and Jersey 1, the changes to the Java API of Atlassian REST are some of the most significant. The new API is based on JAX-RS 2 but continues to work much as you would expect. We have taken the opportunity to more clearly define the public API, so some types have disappeared from the OSGi context, but the API should provide alternatives for all use cases.

Removed libraries

As outlined in this post, we are reducing the number of external libraries that are exported from the Platform by default. The different Atlassian Data Center products will largely align with these removals. These removals have been made possible by the changes made to our API. At this moment, we believe this list is final and complete.

If your app relies on any of these modules, you will need to start adding these dependencies to your app directly and bundle them with your app. We are actively investigating whether we need to raise upload Marketplace limits to accommodate this.

Java 17

From Platform 7 onwards, we will start compiling against Java 17. This means we will no longer support Java 8 and 11. Moving forward, all the latest releases of our Data Center products will be compatible with Java 17 runtime (insofar as they are not yet).

We realize that the requirement to upgrade to Java 17 has raised concerns. We are analyzing the possibilities to reduce the effort on your side and help you with the migration.

Test the changes

While we are working on the detailed migration guides, there are several ways to experiment with the changes already. These methods were never designed to be official but in light of the scale of the upcoming Platform release, we are sharing them regardless.

Platform BOM

The POM files linked above (platform-public-api and platform-deprecated-public-api) can be used as a “Maven BOM”. You can add the following snippet to your POM configuration:

<dependencyManagement>
  <dependencies>
    <dependency>
        <groupId>com.atlassian.platform.dependencies</groupId>
        <artifactId>platform-public-api</artifactId>
        <version>${platform.version}</version>
        <type>pom</type>
        <scope>import</scope>
    </dependency>
    <dependency>
        <groupId>com.atlassian.platform.dependencies</groupId>
        <artifactId>platform-deprecated-public-api</artifactId>
        <version>${platform.version}</version>
        <type>pom</type>
        <scope>import</scope>
    </dependency>
  <dependencies>
<dependencyManagement>

This configuration will automatically update the versions of Atlassian components and third-party libraries provided through OSGi (assuming your configuration doesn’t set it explicitly).

:warning: Please note that together with API changes, in some cases you may have to change the Maven module you depend on. We will provide more details in the migration guides when they are ready.

Products on Platform 6.5 or EAPs

We tried to fit as much preparation for the next major version as possible in Platform 6.5. This version contains most of the API deprecations and replacements. It also already provides the REST v2 component.

Based on our best knowledge, all products plan to migrate to Platform 6.5 soon:

You can use those versions to test API changes in a production-like environment.

We are also releasing RefApp (see About the Atlassian RefApp ) together with the Platform. In some cases you could use it to test your app on a new Platform 7 milestone.

REST v2

REST v2 was added in Platform 6.5. The products that implement it provide it at runtime. To test the compatibility of an app with the new REST implementation, you can:

  1. Remove Maven dependencies related to Atlassian REST and JAX-RS (jsr311-api).
  2. Add Maven dependencies to REST v2 API 7.2.0 and JAX-RS API (jakarta.ws.rs-api).
  3. Add the following snippet to your atlassian-plugin.xml file:
<rest-migration key="unique-key">
    <rest-v2/>
</rest-migration>
  1. Resolve any compilation errors.

We will also share a detailed migration guide to help resolve compilation errors and ensure all the features are used correctly.

Next updates

At this time, our engineers are still finishing the changes for Platform 7. Therefore, we cannot yet provide you with a final build containing all the changes. Our priority is to get a stable version of Platform 7 ready and integrated into the Atlassian Data Center products to get an EAP in your hands as soon as possible.

In the meantime, we are putting together detailed migration guides for all the changes to make the migration as smooth as possible. We are also using your feedback to identify common challenges and pain points and will provide guidance where necessary.

The changes in Platform 7 will be introduced in the next major version of every Atlassian Data Center product. Each product will update its EAPs at its own pace. Products will make specific changes, including API cleanup and removal of third-party libraries. Product-specific changes will be communicated through regular channels.

We highly appreciate all the feedback we got in response to our earlier communications, and we are doing our best to provide clear information on what is to come. Stay tuned.

10 Likes

@MarekTokarski Thanks for the update. Above you mention “we expect to release the stable version of Platform 7 by early Q2 2024.” In previous posts I saw Q2 and Q3 GA release targets but I don’t think anything official from Atlassian has been posted.

It would be helpful to also let us know the timeframe being planned between stable version dates and GA dates so we can plan and test accordingly.

Getting those migrations guides out soon is critical so we don’t waste our time.

Thank you

6 Likes

Thanks @MarekTokarski for this post.
I second Jeff: we should have time and a clear path to help us prepare fir this breaking changes.
When you say

all products plan to migrate to Platform 6.5 soon: Confluence 8.8

What do you mean by “soon”? Since there is an breaking API change, can we count on a 3 month depreciation period? There are a lot of different initiatives happening at the moment, so I hope we will have enough time to prepare our apps for these critical changes.

Thanks

3 Likes

:one: :orange_square: Could you please answer my Plattform 7 question regarding OSGI Imports for Log4J+HttpClient+CommonsLogging+Slf4j, thanks:



:two: :white_check_mark: I followed the REST V2 notes and got it working

  • Tested in official Docker image Confluence 9.0.0-m8
  • BUT I get this error in my unit tests:
java.lang.RuntimeException: java.lang.ClassNotFoundException: org.glassfish.jersey.internal.RuntimeDelegateImpl
  • Should I go with these dependencies (below) to make it work?
  • What is the correct sope for all these dependencies?
  • Should jersey-common be scope=test?
  • Should the javax.servlet:javax.servlet-api pulled in by atlassian-rest-v2-api be excluded, because the enforcer plugin complained?
  • How can I even “see/test” that my REST API is now V2?
  • Why did my v1 REST App (before I made these changes) work in Confluence 9.0.0-m8?
  • I get errors for @JsonProperty and @JsonAutoDetect, what is the replacement?
    • Can I safely use: org.codehaus.jackson:jackson-core-asl:1.9.13 to make it work?
        <!-- CONFLUENCE 9 REST V2 ADD -->
        <dependency>
            <groupId>jakarta.ws.rs</groupId>
            <artifactId>jakarta.ws.rs-api</artifactId>
            <version>2.1.6</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>com.atlassian.plugins.rest</groupId>
            <artifactId>atlassian-rest-v2-api</artifactId>
            <version>7.2.0</version>
            <scope>compile</scope>
            <exclusions>
                <exclusion>
                    <groupId>javax.servlet</groupId>
                    <artifactId>javax.servlet-api</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>org.glassfish.jersey.core</groupId>
            <artifactId>jersey-common</artifactId>
            <version>2.22.2</version>
            <scope>test</scope>
        </dependency>
        <!-- CONFLUENCE 9 REST V2 REMOVE
            <dependency>
                <groupId>javax.ws.rs</groupId>
                <artifactId>jsr311-api</artifactId>
                <version>1.1.1</version>
                <scope>provided</scope>
            </dependency>
            <dependency>
                <groupId>javax.xml.bind</groupId>
                <artifactId>jaxb-api</artifactId>
                <scope>provided</scope>
            </dependency>
            <dependency>
                <groupId>com.atlassian.plugins.rest</groupId>
                <artifactId>atlassian-rest-common</artifactId>
                <scope>provided</scope>
            </dependency>
        -->
        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-annotations</artifactId>
            <version>2.16.1</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-core</artifactId>
            <version>2.16.1</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <!-- For @JsonAutodetect and @JsonProperty -->
            <groupId>org.codehaus.jackson</groupId>
            <artifactId>jackson-core-asl</artifactId>
            <version>1.9.13</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
            <version>2.16.1</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>com.fasterxml.jackson.dataformat</groupId>
            <artifactId>jackson-dataformat-xml</artifactId>
            <version>2.16.1</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>com.fasterxml.jackson.dataformat</groupId>
            <artifactId>jackson-dataformat-yaml</artifactId>
            <version>2.16.1</version>
            <scope>compile</scope>
        </dependency>


:three: :orange_square: Please clarify if this is correct, regarding the boms:

Confluence 9:

...
<confluence.version>9.0.0-m08</confluence.version>
<platform.version>7.0.0-m14</platform.version>
..
        <dependencies>
            <dependency>
                <groupId>com.atlassian.confluence</groupId>
                <artifactId>confluence-plugins-platform-pom</artifactId>
                <version>${confluence.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
            <dependency>
                <groupId>com.atlassian.platform.dependencies</groupId>
                <artifactId>platform-public-api</artifactId>
                <version>${platform.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
            <dependency>
                <groupId>com.atlassian.platform.dependencies</groupId>
                <artifactId>platform-deprecated-public-api</artifactId>
                <version>${platform.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>

Confluence 8.8

...
<confluence.version>8.8.0-beta1</confluence.version>
<platform.version>6.5.5</platform.version>
..
        <dependencies>
            <dependency>
                <groupId>com.atlassian.confluence</groupId>
                <artifactId>confluence-plugins-platform-pom</artifactId>
                <version>${confluence.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
            <dependency>
                <groupId>com.atlassian.platform.dependencies</groupId>
                <artifactId>platform-public-api</artifactId>
                <version>${platform.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
            <dependency>
                <groupId>com.atlassian.platform.dependencies</groupId>
                <artifactId>platform-deprecated-public-api</artifactId>
                <version>${platform.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>

Is this correct?


Thanks a lot :slight_smile:

2 Likes

Hi @MarekTokarski

In the Products on Platform 6.5 or EAPs section you didn’t specify the Jira 9.15 and Bamboo 9.6 versions, although they were mentioned in another discussion by @MalathiVangalapati (Announcing Data Center Platform 7.0. Next step to improve our security posture). Can you confirm that platform 6.5 will indeed be available on Jira 9.15 and Bamboo 9.6 ?

Fabien [Elements]

1 Like

Hi @jeff

My post specifies the dates of only “Platform” release. Products need to update the “Platform” which takes time, but they also have their own updates to make. Every product has its own timeline and the path to adopt changes made by our team, we are mostly supporters in this process.

For product specific timelines, please refer to the product specific communication. They have the full knowledge about the effort and scope of work on their side.

Getting those migrations guides out soon is critical so we don’t waste our time.

I completely understand that request. Our team is prioritizing it at the moment.

1 Like

Hi @dusan.spaic

The “Platform” is responsible for the changes in common (cross-product) components. Products are the owners of the timeline and full list of changes - in addition to the “Platform”. Based on that I cannot freely speak about the timelines, because I don’t have the full context.

Since there is an breaking API change, can we count on a 3 month depreciation period?

All products are aware of requirement to provide deprecation period and when planning the rollout it was taken into account.

You were referring to my comment about “Platform 6.5”. I would like to reassure you - that version provides most of the API changes that we will introduce in the “Platform 7”. The “Platform 6.5” is backward compatible, we were adding new API to that release. “Platform 7” will simply remove the old API and thus will be incompatible with previous versions.

1 Like

Hi @clouless

I will try to answer all your concerns here :slight_smile:

:one: :orange_square: Plattform 7 question regarding OSGI Imports for Log4J+HttpClient+CommonsLogging+Slf4j

I understand that we explicitly mentioned compiled dependencies as a solution for our removal of certain 3rd party libraries. I would argue however, that your setup is a little bit extereme.

First of all you have to be careful with compiled scope. It is transitive, so you may introduce some unwanted dependencies to your product (e.g. that should be actually provided). In the plugins I prefer to keep the number of compiled dependencies to minimum and I always check also transitive ones to ensure it contains what I expect (you can run mvn dependency:tree).

In your dependencies I can see couple categories of libraries. The first one starts from guava to httpclient. I understand we removed some of them from the public API - are you sure your plugin needs it? If yes, then it is ok, but I would always double check if a dependency is really needed.

The second category is jackson. I understand that at the moment REST v2 supports only JAXB annotations. We are analysing at the moment if we can do something about it. In the current context it make sense to have it in compiled scope, but again I would double check if all of them are required.

The third category are logging dependencies. As you mentioned we are recommending SLF4J. Unless you want to make some advanced logging (that I’m not even sure if it would work with product’s configuration), I would recommend simply putting slf4j-api provided dependency. Products are setting up the whole logging engine, and SLF4J API should be enough to see the log messages from your plugin.

I suspect some of those dependencies may be needed during tests. Setting the correct scope is important here - compiled means the dependency is used by the production code (directly) and thus it will be copied to the final jar. While provided suggests a directly used dependency that will be provided at runtime (in this case by the Atlassian product). The test scope may be useful to provide some implementations (or mocks) that your code doesn’t interact directly, but they help with proper test execution.

:two: :white_check_mark: I followed the REST V2 notes and got it working

Tested in official Docker image Confluence 9.0.0-m8

Honestly I was suspecting Confluence didn’t add REST v2 yet to their milestones.

What is the correct sope for all these dependencies?

Dependencies provided by Atlassian product (defined in platform-* POM-BOMs) should be always provided.

Should jersey-common be scope=test?

Probably yes, but I would double check if your plugin really needs that dependency.

Should the javax.servlet:javax.servlet-api pulled in by atlassian-rest-v2-api be excluded, because the enforcer plugin complained?

atlassian-rest-v2-api should be definitely a provided dependency - it will be provided at runtime through OSGi from the REST v2 plugin.

How can I even “see/test” that my REST API is now V2?

I will write down that we should clearly explain how you can check that. Quickly thinking, you can check the OSGi console and check from where your plugin takes dependencies. REST v2 API and JAX-RS 2 specific packages should be imported from REST v2 plugin.

Why did my v1 REST App (before I made these changes) work in Confluence 9.0.0-m8?

There are 2 factors. We designed REST v2 in a way it can interoperate with REST v1 in the same product - that is why REST v2 was already included in REST v1. Our milestones (including product specific ones) show the work in progress. REST v1 will be removed from the products at some point before the final release. I suppose, Confluence didn’t remove that plugin yet. Removing it late in the process should help you and other partners with migration (I hope so :slight_smile: )

  • I get errors for @JsonProperty and @JsonAutoDetect, what is the replacement?
    • Can I safely use: org.codehaus.jackson:jackson-core-asl:1.9.13 to make it work?

I’m not sure what is the type of errors, so I cannot help here. You can use Jackson 1 if you want. In fact you can use any marshalling/unmarshalling library as long as it will be compiled. You just need to ensure that the MessageBodyReader MessageBodyWriter compatible with JAX-RS 2 API will be registered. The registration works exactly the same as in the REST v1 - you can use @Provider annotation or use META-INF/services mechanism.

Looking at your dependencies and the questions you asked, I suspect Confluence milestone in fact doesn’t contain REST v2 yet :confused: For sure it will be added in one of the following milestones. If you want to simply try to write a plugin for REST v2, you could use RefApp.

:three: :orange_square: Please clarify if this is correct, regarding the boms:

I assume those dependencies are wrapped in dependencyManagement tag. If yes, then it seems to be correct. However I’m not familiar with artifact confluence-plugins-platform-pom and I don’t know if it was meant to be a “Maven BOM”.

3 Likes

Ok Thanks a lot for these clarifications :rocket: . I will try to strip down my dependencies and try to change the scope to test for all the logging stuff :slight_smile:

Unfortunately I will need HttpClient and this pulls in commons-logging which is needed by HttpClient somehow. I tested it and it does not seem to work if it is provided only. Also commons-logging pulls in a lot of optional stuff which I marked as optional in the osgi imports. That was the only way it worked for me.

Guava is needed for some unicode string replacements the App does, maybe I can convert this to vanilla java replacement logic. Maybe I can get rid of GSON too, since I used @JsonProperty and GSON in combination to generate JSON manually in some situations and this could be replaced by JAX-RS serialization logic…

I will give it another spin in the next days and try to what outcome I can trim down the dependencies.

:slight_smile:

1 Like

Hi @FabienPenchenat

I didn’t want to mention specific feature versions of the products, if they didn’t make it public yet. Together with @MalathiVangalapati we double checked and we received confirmation directly from the products, that Platform 6.5 will be present in Jira 9.15 and Bamboo 9.6.

5 Likes

If REST V2 is present in the EAPs but off by default, wouldn’t it make sense to turn it on ASAP? Question for the product teams I guess and not you specifically.

I don’t think many vendors will spot that you have to make a plugin XML change to opt in.

There is no reference to REST V2 in “Preparing for Confluence 9” at all that I can see.

I tried what you suggested and the logging stuff works with only slf4japi

But when I try to use REST V2 without the Jackson apis, then my Rest Endpoints only return 404 and in the logs appears this:

io.atlassian.util.concurrent.LazyReference$InitializationException: A MultiException has 2 exceptions.  They are:
1. java.util.ServiceConfigurationError: com.fasterxml.jackson.databind.Module: Provider com.fasterxml.jackson.datatype.jdk8.Jdk8Module not found
2. java.lang.IllegalStateException: Unable to perform operation: post construct on org.glassfish.jersey.jackson.internal.DefaultJacksonJaxbJsonProvider

So the question: Is the Confluence 9.0.0-m8 not fully ready for REST V2 or what am I doing wrong?

I am simply doing this:

                return Response.ok(listModel).build();

With ListModel being class which is serializable and has @XmlElement annotations.

I’ve run a small experiment on Confluence and indeed it seems that we have a bug in integration between REST v2 ↔ Confluence.

The error I received is:

io.atlassian.util.concurrent.LazyReference$InitializationException: A MultiException has 2 exceptions.  They are:
1. java.util.ServiceConfigurationError: com.fasterxml.jackson.databind.Module: Provider com.fasterxml.jackson.datatype.joda.JodaModule not found
2. java.lang.IllegalStateException: Unable to perform operation: post construct on org.glassfish.jersey.jackson.internal.DefaultJacksonJaxbJsonProvider

I assume your error is caused by similar misconfiguration.

Please give us some time to fix the issue. We will need to make a separate milestone release for that :frowning:

I will make an update here, once it will be ready.

5 Likes

I’ve got confirmation from the Confluence team that Confluence 8.9.0-m16 and 9.0.0-m09 already contain REST v2. They are active by default, but you have to add the small snippet I included in the original post (rest-migration) - it is required to maintain backward compatibility. It won’t be required in the final Platform 7 release and become obsolete then.

As I mentioned in Platform 7 upgrade in progress: Learn about the first highlights and changes - #13 by MarekTokarski I discovered a bug that prevents proper REST v2 context initialization. We are working on fixing it now.

2 Likes

I don’t understand why this is an opt in? If REST V1 is removed in the final release, surely the EAP should behave as if it has been already.

Vendors are unlikely to spot they need to add some XML to opt in, and will only see the REST V2 changes in the final milestone otherwise.

I understand it being an opt in for Confluence 8.8, but not the 9 EAP?

1 Like

Hi Marek,
That sounds great :rocket: I was almost ready for retirement :sweat_smile:

I will wait then and continue the fun with Platform 6.5 and Confluence 8.8 until a new Confluence 9 EAP is available :muscle:

Cheers

2 Likes

I would assume that REST v1 will be removed in one of the next EAPs. At the moment we are going through the same migration you are/will be. In the current state Confluence simply wouldn’t start without REST v1.

4 Likes

That makes sense, thanks for the clarification!

1 Like

Hi @MarekTokarski,

Thanks for summarizing all the updates in a single post.

I have same questions about the linked POM file for platform-public-api.

How should we understand the dependencies listed there?
How should we read this document?
Does each dependency listed in this pom mean that it will be available in Jira 10?

Example (some use case):

a) Some plugin use commons-lang library in application.
b) The commons-lang library is included in the dependencies list in the platform-public-api pom file.

Considering the sentence: “platform-public-api 19 dependencies exported through OSGi and publicly available to all apps.”

Is it enough to set the scope of the commons-lang dependency to provided in this application?

Additionally, how does this set of dependencies in platform-public-api relate to the article Announcing Data Center Platform 7.0. Next step to improve our security posture, which states that commons-lang will be removed from Platform 7?

Another example:

In the document Announcing Data Center Platform 7.0. Next step to improve our security posture, we can see that the dependency opensymphony:propertyset will also be removed, but it still exists in the platform-public-api POM file. Based on the information provided, can we safely use this dependency with the provided scope in application that relies on propertyset classes?

Cheers,
Rafał

6 Likes

Hi @rafal.janiczak1

Your understanding is correct. The components defined in platform-public-api are expected to be exported to the Plugin System - in all products. If they aren’t, it means either a bug on the product side or misdefinition on the Platform level. Of course products are allowed to export more packages if they want/need to.

For the components that are defined in platform-public-api the recommended scope is provided. AMPS will generate proper Import-Package declarations and your plugin will use the code provided by the product at runtime. In most cases this is what we all are expecting :slight_smile:

I checked the current definition of platform-public-api. You are right, there is a mismatch. The list mentioned in the post is effective. I’m sorry for that. I will update our POMs to reflect the change and double check if we have more similar issues there.

4 Likes