Preparing for Jira Software 10.0 and Jira Service Management 6.0 - multiple EAPs coming your way

agniadzik · April 16, 2024, 9:00am

Actually this will be changed a bit:
DELETE /rest/api/2/version/{id} will be changed to get the semantics of POST /rest/api/2/version/{id}/removeAndSwap while the latter will become deprecated

@AndrzejKotas @BrunoMarotta sorry for the confusion.
We will stick to the version published earlier.

AndrzejKotas · April 16, 2024, 9:03am

yes everything will be part of the change log as we
release the eap https://developer.atlassian.com/server/jira/platform/changelog/

we’re trying using this thread to get you the information on what to expect earlier.

rlander · April 16, 2024, 9:14am

I’ve said it elsewhere, but I far prefer the legacy “Preparing for Jira X” pages to the new changelog.

It made it easy to link to one page for changes impacting a version, now you have to search for Jira 10, and most of the detail is buried in expands.

clouless · April 18, 2024, 5:00pm

Is there a problem with logging and slf4j?

I do the same thing as with Confluence 9.0 on Jira 10.0 but get no log messages. Only

SLF4J(W): No SLF4J providers were found.
SLF4J(W): Defaulting to no-operation (NOP) logger implementation
SLF4J(W): See https://www.slf4j.org/codes.html#noProviders for further details.

I use in my pom.xml

        <!-- JIRA 10 LOGGING START -->
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-api</artifactId>
            <version>2.22.1</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
            <version>2.22.1</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-api</artifactId>
            <version>2.0.11</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-slf4j-impl</artifactId>
            <version>2.22.1</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-slf4j2-impl</artifactId>
            <version>2.22.1</version>
            <scope>test</scope>
        </dependency>
        <!-- JIRA 10 LOGGING END -->

UPDATE Solved with making log4j-slf4j2-impl and log4j-slf4j-impl scope=compile

        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-slf4j-impl</artifactId>
            <version>2.22.1</version>
            <scope>compile</scope>  <======= COMPILE
        </dependency>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-slf4j2-impl</artifactId>
            <version>2.22.1</version>
            <scope>compile</scope>  <======= COMPILE
        </dependency>

But why does this work on Confluence 9.0 with Platform 7?

Is this a valid approach?

AndrzejKotas · April 22, 2024, 8:11am

It will be a valid approach once Jira 10 adopts Platform 7.
Current EAP is on 6.5 hence the errors. Platform 7 adoption work is still ahead and will be available in later EAPs.

clouless · April 22, 2024, 8:23am

That info really surprises me. Can you please explicitly tell this to us once the real Platform 7 EAP is here. I already thought I was Jira 10 ready and now you tell me this … thanks

ashraf.teleb85 · April 29, 2024, 11:56pm

Can you please explain how to make OSGi imports of a plugin mandatory?

All I’m getting now is a one line error with no details as follows:

[INFO] [talledLocalContainer] JIRA plugin: There was a problem loading the module descriptor: com.myapp.jira.plugin.ViewerPanel. Unable to enable web fragment

Thanks

AndrzejKotas · April 30, 2024, 1:59pm

Hey folks, ‘OCNB’,
we were prepping to ship the newest EAP build to you today but found that https://jira.atlassian.com/browse/JRASERVER-77643 is also affecting our 10.0 / 6.0 build. EAP is coming, but we need to apply a fix first.
We will keep you posted.

nhan-nguyen · May 2, 2024, 2:18pm

@AndrzejKotas workflow-function and dialog does not work with 10.0.0-m0002. The .vm file is not rendered at all. It shows blank. I’m building with Java 17. Is it a known issue?

pch · May 6, 2024, 5:45pm

“The global object GH.RapidBoard is deprecated.”
What does it mean?

Will the GH be removed? Will there be a way to access it?

clouless · May 6, 2024, 7:27pm

Jira 10.0.0 EAP03 is available - but no docker image in sight

Where is atlassian/jira-software:10.0.0-EAP03-ubi9-jdk17 ?
it is here now

SEE CHANGE-1623: https://developer.atlassian.com/changelog/#CHANGE-1623

adam.labus · May 7, 2024, 6:31am

Hi @AndrzejKotas,

do you know how to properly configure dependencyManagement in pom.xml so that the artifact below is downloaded without declaring a specific version?

Unfortunately, without the version I cannot compile the application :(, but if I use the version 10.0.0-fb408b0b3 it does not work for EAP03

<dependency>
            <groupId>com.atlassian.jira</groupId>
            <artifactId>jira-projects-plugin</artifactId>
            <scope>provided</scope>
</dependency>

We use the following classes in our application:

com.atlassian.jira.projects.shortcuts.ProjectShortcut;
com.atlassian.jira.projects.shortcuts.ShortcutsService;

pom.xml

<jira.version>10.0.0-m0004</jira.version>
<jira.servicedesk>6.0.0-m0004</jira.servicedesk>
<platform.version>7.0.0-m59</platform.version>

Cheers
Adam

mrzymski · May 7, 2024, 12:14pm

Hi Przemysław,
let me answer your question. I suppose you got this message from the dev console coming from ‘jira/legacy/namespace’/AJS.namespace wrapper?
I’ll start from stating that we are not planning to remove global variables in this platform release (10.0.0).
At the same time, we are committed to reducing the tech debt and introducing improvements to the Jira Front-End tech stack and UI. Global variables tend to be an obstacle in such projects. We communicated the long-term take on global variables when Preparing for Jira 8.0 and reinforced that message later too.
The most recent effort in that area to my knowledge was in JSW 9.7.
You can read more about the migration from global variables to AMD modules on this page. It’s been published in 2019 but the gist is intact. Below, I’ll provide key points:

All supported functionality should be already available in a form of AMD modules (vs global variables).
All possible usage of globals is considered as deprecated and developers should have a plan to move to alternative solutions (AMD modules).
Global variables that provide support for supported functionality will be removed only when an alternative solution for that piece of functionality is in place, and with proper notice beforehand. We may remove globals without the alternative solution in place for unsupported functionality, in platform releases, or for security reasons.
We cannot promise that in the future all AMD modules will be a part of the API.
Once we decide to remove a particular subset of globals, we will provide a detailed migration documentation, containing removed globals list and their AMD module names equivalents.

I hope this clarifies the matter for Jira 10 as well as sets expectations for next versions.

Cheers,
Maciej

rlander · May 9, 2024, 2:09pm

More dependency issues:

Could not resolve com.atlassian.jira:jira-software-application-parent:10.0.0-m0004.
Could not resolve com.atlassian.jira:jira-software-application-parent:10.0.0-m0004.
Could not parse POM https://packages.atlassian.com/mvn/maven-external/com/atlassian/jira/jira-software-application-parent/10.0.0-m0004/jira-software-application-parent-10.0.0-m0004.pom
Could not find com.atlassian.jira:jira-internal-bom:10.0.0-QR-20240417132847.
Searched in the following locations:
- https://packages.atlassian.com/mvn/maven-external/com/atlassian/jira/jira-internal-bom/10.0.0-QR-20240417132847/jira-internal-bom-10.0.0-QR-20240417132847.pom
- https://nexus.adaptavist.com/content/groups/staff-ess/com/atlassian/jira/jira-internal-bom/10.0.0-QR-20240417132847/jira-internal-bom-10.0.0-QR-20240417132847.pom
- https://nexus.adaptavist.com/content/groups/staff-ess/com/atlassian/jira/jira-internal-bom/10.0.0-QR-20240417132847/jira-internal-bom-10.0.0-QR-20240417132847.jar
- https://nexus.adaptavist.com/content/repositories/atlassian-maven2/com/atlassian/jira/jira-internal-bom/10.0.0-QR-20240417132847/jira-internal-bom-10.0.0-QR-20240417132847.pom

Any hints?

AndrzejKotas · May 9, 2024, 3:07pm

Could not find com.atlassian.jira:jira-internal-bom

Looks like you’re trying to use internal bom, there are multiple BOM files, each serving different functions:

jira-api-bom: This BOM is designed for external products. It offers a centralized location for managing the dependencies of external products, ensuring that they’re using the correct, up-to-date versions of dependencies.
jira-deprecated-api-bom: This BOM lists libraries that may undergo changes or be removed from the public Bill of Materials in future updates.
jira-internal-bom: This BOM is intended for internal products. It provides a centralized location for managing internal dependencies, ensuring consistency across all internal products.
jira-bundled-plugins-bom: This BOM manages the versions of apps bundled with Jira.

Please make sure to review https://developer.atlassian.com/server/jira/platform/changelog/#CHANGE-1551 introduced in EAP#2.

rlander · May 9, 2024, 3:14pm

We’re not using it directly though, it’s a dependency of jira-software-application-parent which is a dependency of jira-software-application

Could not resolve com.atlassian.jira:jira-software-application:10.0.0-m0004.
Required by:
project :jira
Could not resolve com.atlassian.jira:jira-software-application:10.0.0-m0004.
Could not parse POM https://packages.atlassian.com/mvn/maven-external/com/atlassian/jira/jira-software-application/10.0.0-m0004/jira-software-application-10.0.0-m0004.pom
Could not resolve com.atlassian.jira:jira-software-application-parent:10.0.0-m0004.
Could not resolve com.atlassian.jira:jira-software-application-parent:10.0.0-m0004.
Could not parse POM https://packages.atlassian.com/mvn/maven-external/com/atlassian/jira/jira-software-application-parent/10.0.0-m0004/jira-software-application-parent-10.0.0-m0004.pom
Could not find com.atlassian.jira:jira-internal-bom:10.0.0-QR-20240417132847.
Searched in the following locations:

We depend on jira-software-application to get the .obr for the application, we use this in our build to start up Jira.

gengulay · May 10, 2024, 3:34am

hello @FilipNowak I tried your suggestions making OSGi imports of my plugoin mandatory by adding this line:

  <!-- Add package import here -->
            <Import-Package>
 org.springframework.osgi.*;resolution:="mandatory",
...

but I get this error

Also tried to explicitly import the package that I depended on and have the version mismatch error that you mentioned?

Also found a similar issue on Jira 8 EAP that seems have been eventually fixed in subsequent more stable releases here, Classes not found in Jira 8.0 EAP - #3 by carlos.fernandez

any chance this will fix itself on later EAP versions?

cheers,

adam.labus · May 10, 2024, 5:20am

Hi @AndrzejKotas ,

I can confirm what @rlander wrote Preparing for Jira Software 10.0 and Jira Service Management 6.0 - multiple EAPs coming your way - #77 by rlander. We use the following configurations and have the same problem.
Additionally, we have a problem with this artifact

<dependency>
            <groupId>com.atlassian.jira</groupId>
            <artifactId>jira-projects-plugin</artifactId>
            <scope>provided</scope>
</dependency>

can you take a look at it? (link - Preparing for Jira Software 10.0 and Jira Service Management 6.0 - multiple EAPs coming your way - #73 by adam.labus)

pom.xml

<dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>com.atlassian.jira</groupId>
                <artifactId>jira-api-bom</artifactId>
                <version>${jira.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>
    </dependencyManagement>

Cheers
Adam

FilipNowak · May 10, 2024, 6:51am

Hi again @gengulay!
It looks like you have not migrated your plugin to RESTv2 completely.
Do you have a

    <rest-migration key="<plugin-key-or-anything-you-want>">
        <rest-v2/>
    </rest-migration>

tag in atlassian-plugin.xml descriptor?
This would make the resolver hook force correct (2.x) javax.ws.rs version import.
You can also follow the more detailed instructions in Bitbucket to migrate the plugin completely.

AndrzejKotas · May 10, 2024, 11:25am

thanks for more details @rlander, we’re investigating it further.