Which AMPS version to use?

agaranin · May 23, 2024, 5:57pm

Hi,
We have several custom plugins that currently run on Jira 9.4. As we are getting ready to upgrade to Jira 9.12, we are updating the plugins as well, and here comes the question of which AMPS version to use?
One of the plugins has a compile dependency on a library, which in turn has some compile dependencies on 3rd-party libs, like jackson-databind, for example.
Previously it wasn’t an issue. During build maven would pack all the transient dependencies into the resulting jar.
Now, if I’m trying to build the plugin with the latest AMPS (8.16.0 at the moment), or 8.14.x-8.15.x, build fails because of “banned dependencies” and “make sure platform artifacts are not included”.
I understand the rationale, so I tried adding those dependencies into my plugin as provided.

The plugin builds successfully, but when I try to run in in Jira, I get NoClassDefFound exceptions for those 4rd-party libs. And when I look at the “system bundle” in OSGi browser, I don’t see those libs (jackson-databind in particular).

So, I was thinking, maybe I should be using a different version of AMPS? I couldn’t find any guide for that, does it exist?

jens · May 24, 2024, 6:14am

Update to 8.16.0, set your dependency scopes as you need them, and set <skipBanningDependencies>:

<plugin>
                    <groupId>com.atlassian.maven.plugins</groupId>
                    <artifactId>confluence-maven-plugin</artifactId>
                    <version>8.16.0</version>
                    <configuration>
                        <skipBanningDependencies>true</skipBanningDependencies>
                        ...

mkemp · May 24, 2024, 4:22pm

I always recommend the latest version, it’s the one with the most bugfixes, the only one we support for the sake of sanity (to avoid the compatibility matrix getting very complex), and where all the new features are.

While it gets things compiling, the reason we add to the banned dependencies is to avoid headaches with OSGi package imports (and exports). If you know what you’re doing you can compile scope them, but then you need to be careful not to rely on any of our APIs that use these libraries. Even if they’re the same class, you can run into problems because the classloaders used are different and thus to the JVM they’re not the same class.

A more explicit way to only ignore some specific dependencies (while keeping the check around more broadly for new changes and/or catching mistakes) is like this:

<configuration>
    <banningExcludes>
        <exclude>groupid:artifactId</exclude>
    </banningExcludes>

I know this isn’t documented here, I’ll raise that

agaranin · May 24, 2024, 5:38pm

Thanks guys, that’s helpful!

But I feel there’s still some inconsistency there, or I am missing something obvious.
I can add excludes, no problem, but why the library is banned and NOT provided at the same time?

My specific example:
My plugins has this dependency:

        <dependency>
            <groupId>com.some.library.package</groupId>
            <artifactId>some-library</artifactId>
            <version>1.0.0</version>
            <scope>compile</scope>
        </dependency>

This library has this in pom.xml:

        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
            <version>2.12.5</version>
            <scope>compile</scope>
        </dependency>

If I try to build it as is (without exclusions), I get the error, for example:

Found Banned Dependency: com.fasterxml.jackson.core:jackson-databind:jar:2.12.5

So, I presume, since its a “platform artifact” it should be provided, right?
Looking at Managing dependencies, I tried adding jackson-databind as a provided dependency, but that didn’t work, my plugin don’t see the classes.

What I might be missing? My point is, why banning a plugin from including something, if that something is not available to the plugin otherwise? Just to bring developer’s attention to potential conflict?

MateKavaleczMidori · June 4, 2024, 9:57am

I agree with @agaranin, the banning feature is currently completely broken.
It either needs to be deprecated and set to be disabled by default for everyone OR updated with the correct list.
You can’t expect people to manually fight against your system all the time.

mkemp · June 7, 2024, 7:33am

AMPS can only guess what platform version is being targeted. It sounds like it’s guessing it’s 7.0 which is the most recent minors of all the products and the upcoming major releases.

If Jackson v2 isn’t provided it’s probably from trying to use it with an older product versions.

If you’re targeting both old and new product versions with the same build you’ll probably need to compile scope this and write the package import instructions for fasterxml.jackson which is heavily tied to using REST v2.

If you’re only targeting older product versions then you can leave this compile scope and tell AMPS what you’re targeting by setting platformVersion to whatever is appropriate, e.g.

<configuration>
    <platformVersion>6.5.22</platformVersion>

Another thing that wasn’t documented, I’ll raise that.

The list should be correct with the right version specified. Is there a specific dependency and product version you’ve found to be incorrect?

It should be pretty quick to run mvn amps:validate-banned-dependencies as you update the pom.xml file and it probably only needs to be done once a year or so from now on. Previously the list was entirely manually populated, but from now on it should be based on the platform version.

MateKavaleczMidori · June 7, 2024, 8:57am

I did not know about this configuration option earlier, thanks for the info!

This is my current output (with the platform set to the latest I found in the Maven repo):

[INFO] --- amps-maven-plugin:8.16.2:validate-banned-dependencies (default-validate-banned-dependencies) @ better-pdf-exporter-for-jira ---
[INFO] validate banned dependencies
[INFO] Dependencies excluded from banning: []
[INFO] Platform version range: '7.0.9'
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.BannedDependencies failed with message:
make sure platform artifacts are not bundled into plugin
Found Banned Dependency: com.google.code.findbugs:jsr305:jar:3.0.2
Found Banned Dependency: com.fasterxml.jackson.core:jackson-core:jar:2.16.2
Found Banned Dependency: com.fasterxml.jackson.module:jackson-module-jaxb-annotations:jar:2.16.2
Found Banned Dependency: com.fasterxml.jackson.core:jackson-databind:jar:2.16.2
Found Banned Dependency: commons-io:commons-io:jar:2.15.1
Found Banned Dependency: com.google.guava:guava:jar:33.0.0-jre
Found Banned Dependency: com.fasterxml.jackson.core:jackson-annotations:jar:2.16.2
Use 'mvn dependency:tree' to locate the source of the banned dependencies.

I might be wrong, but as far as I know, Guava was removed a long time ago, so that ban seems to be wrong. The com.google.code.findbugs:jsr305 was also imported by Guava.
Even Atlassian seems to be conflicted about including Jackson or not, given the recent announcement that it would be included again, regardless of the earlier exclusion, so feel free to ignore that for now.

Don’t get me wrong, I have no issue with having to validate the dependencies! It is in fact a very good idea to have a feature like this, as long as the list it works from is correct. But if we need to manually exclude packages from a banlist after reading a multitude of upgrade guides on a community forum, the whole thing becomes pointless.

For this to be actually useful from a plugin developer point of view, it should allow specifying a range of platforms to support, and only ban dependencies that are banned on all versions in that range. If a dependency is not banned in any versions in the provided range, it needs to be compiled, otherwise the app won’t work on that version. AFAIK the only way to do this currently is by manually excluding stuff from the banlist, which is already not ideal.

Realistically speaking, I don’t think there’s a single vendor out there who would want to support only 1 platform version. (We might be forced to do that in some cases, but that doesn’t mean we want to.)

mkemp · June 11, 2024, 9:14am

That all looks correct, other than Guava which I need to double-check. Guava has been complicated to kill. From what I can see, it’s because AMPS is banning our internal API for vendors too. I’ll raise this with the appropriate teams

We dropped Jackson v1 and took a while to figure out if we wanted to put Jackson v2 in. We ultimately decided to add it because we needed it to provide all the same capabilities to plugins as we had previously. It’s hard to get everything done with pure javax APIs.

Everything we’ve built is on the assumption of no cross-major compatibility, we have to break API at some point with some things. Of course we know vendors try anyway, so

I’ll raise with the team that owns AMPS.

agaranin · June 25, 2024, 6:41pm

Thanks for all the answers, just a few things I’m trying to clarify for myself.

When you say “If Jackson v2 isn’t provided it’s probably from trying to use it with an older product versions.” Does it mean newer product versions will be providing Jackson2? If so, what is “old” and what is “new”? We are targeting 9.12 which is the latest LTS, but not the latest on its own. Is it considered old in this context?

How can I reliably find what packages are actually provided by Jira? By looking at System Bundle in OSGi browser, or some other way? It seems, Jira 9.12 is using it (it is present in atlassian-jira/WEB-INF/lib/), but not providing it.

Speaking of <platformVersion>6.5.22</platformVersion>. Is there a reference, which platform version is applicable. Can I, for example, find it in Jira source code somewhere?

mkemp · June 25, 2024, 9:09pm

Yes, from Platform 6.5

Pre/post-platform 6.5

Yes, and if you go to /plugins/servlet/upm/osgi and expand the Export Package section for “System Bundle”, you’ll see that com.fasterxml is missing

atlassian / platform-module-usage / wiki / new-platform — Bitbucket and the POMs

agaranin · June 25, 2024, 9:28pm

Thanks!

ViacheslavDobromyslo · August 8, 2024, 6:25am

TLDR; Never update AMPS and Atlassian SDK to the latest versions. Choose wisely which versions are compatible with your target Jira/Confluence/… versions.

The same question I asked myself a few months ago. And after a thorough research with many tries, tests, and failures, I found that the most suitable AMPS plugin version and the related dev stack for both current (August 2024) LTS versions of Jira 9.12 and Confluence 8.5 is as follows:

<properties>
    <jira.version>9.12.12</jira.version>
    <confluence.version>8.5.11</confluence.version>
    <amps.version>8.11.2</amps.version>
    
    <atlassian-plugins-osgi-bridge.version>7.1.9</atlassian-plugins-osgi-bridge.version>
    <osgi.javaconfig.version>0.6.0</osgi.javaconfig.version>
    <jsr311api.version>1.1.1</jsr311api.version>
    <jackson.version>1.9.14-atlassian-6</jackson.version>
    <testrunner.version>2.0.3</testrunner.version>
    <junit.version>4.13.2</junit.version>
    <felix.version>7.0.5</felix.version>
    <spring.version>5.3.34</spring.version>
    <gson.version>2.10.1</gson.version>

    <!-- Java 17 workaround for some Maven plugins -->
    <!-- See for details: https://confluence.atlassian.com/jiracore/java-17-runtime-opens-and- exports-arguments-1188413810.html -->
    <jvm17.opens />
</properties>

<dependencies>
    <!-- Spring Java Config -->
    <dependency>
        <groupId>com.atlassian.plugins</groupId>
        <artifactId>atlassian-plugins-osgi-javaconfig</artifactId>
        <version>${osgi.javaconfig.version}</version>
    </dependency>
    <dependency>
        <groupId>org.apache.felix</groupId>
        <artifactId>org.apache.felix.framework</artifactId>
        <version>${felix.version}</version>
        <scope>provided</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-beans</artifactId>
        <version>${spring.version}</version>
        <scope>provided</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>${spring.version}</version>
        <scope>provided</scope>
    </dependency>
    
    <dependency>
        <groupId>com.atlassian.plugins</groupId>
        <artifactId>atlassian-plugins-osgi-bridge</artifactId>
        <version>${atlassian-plugins-osgi-bridge.version}</version>
        <scope>provided</scope>
    </dependency>

    <!-- TestRunner -->
    <dependency>
        <groupId>com.atlassian.plugins</groupId>
        <artifactId>atlassian-plugins-osgi-testrunner</artifactId>
        <version>${testrunner.version}</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>javax.ws.rs</groupId>
        <artifactId>jsr311-api</artifactId>
        <version>${jsr311api.version}</version>
        <scope>provided</scope>
    </dependency>
    <dependency>
        <groupId>com.google.code.gson</groupId>
        <artifactId>gson</artifactId>
        <version>${gson.version}</version>
        <scope>provided</scope>
    </dependency>

    <!-- Testing -->
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>${junit.version}</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-test</artifactId>
        <version>${spring.version}</version>
        <scope>test</scope>
    </dependency>
</dependencies>

<profiles>
    <!-- Java 17 workaround for some Maven plugins -->
    <!-- See for details: https://confluence.atlassian.com/jiracore/java-17-runtime-opens-and-exports-arguments-1188413810.html -->
    <profile>
        <id>jvm17</id>
        <activation>
            <jdk>17</jdk>
        </activation>
        <properties>
            <jvm17.opens>
                --add-opens=java.base/sun.nio.cs=ALL-UNNAMED
                --add-opens=java.base/java.nio.charset=ALL-UNNAMED
                --add-opens=java.base/java.lang.ref=ALL-UNNAMED
                --add-opens=java.base/java.lang=ALL-UNNAMED
                --add-opens=java.base/java.lang.reflect=ALL-UNNAMED
                --add-opens=java.base/java.util=ALL-UNNAMED
                --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED
                --add-opens=java.base/java.io=ALL-UNNAMED
                --add-opens=java.management/javax.management=ALL-UNNAMED
                --add-opens=java.desktop/sun.font=ALL-UNNAMED
                --add-opens=java.base/sun.reflect.generics.parser=ALL-UNNAMED
                --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED
                --add-opens=java.base/java.time=ALL-UNNAMED
                --add-exports=java.base/sun.util.calendar=ALL-UNNAMED
                --add-exports=java.base/sun.security.action=ALL-UNNAMED
                --add-exports=java.xml/jdk.xml.internal=ALL-UNNAMED
            </jvm17.opens>
        </properties>
        <build>
            <pluginManagement>
                <plugins>
                    <!-- Workaround to avoid InaccessibleObjectException when running `integration-test` and `remote-test` in console -->
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-failsafe-plugin</artifactId>
                        <version>2.22.2</version>
                        <configuration>
                            <argLine>${jvm17.opens}</argLine>
                        </configuration>
                    </plugin>
                </plugins>
            </pluginManagement>
        </build>
    </profile>
</profiles>

Note 1: This was tested on Atlassian Plugin SDK 8.2.10.

Atlassian Plugin SDK 8.2.10 is not available as an installation package for Mac OS, Windows, Linux. You can find it only as Atlassian Plugin SDK - TGZ at: Atlassian Marketplace

Note 2: Java 17 hack is still needed because Atlassian has added not all of the required JVM options. There are some of the options on the list required for testing. To be honest, testing of Jira/Confluence is a separate science with many caveats. I’ve recently shared some of my proven testing experience in another posts.

What’s wrong with the other AMPS versions?

AMPS	Troubles
8.17.1	Dependency `com.atlassian.platform:license-backdo or-plugin:jar:1.0.3` is not available in the public Maven repo.
8.16.0	Provided DevToolBox does not work in Jira 9.12 LTS
8.15.4	Provided DevToolBox does not work in Jira 9.12 LTS
8.14.3	Provided DevToolBox does not work in Jira 9.12 LTS
8.13.5	Is not compatible with Confluence 8.5 LTS. It requires Confluence 8.6.1+
8.12.4	Is not compatible with Confluence 8.5 LTS. It requires Confluence 8.6.1+

Comparison table of the AMPS and Atlassian product versions compatibility

The table below contains minimum supported versions of the Atlassian products and Platform + used versions of Test Runner and Groovy.

AMPS Release	POM	Jira	Confluence	Bitbucket	Bamboo	FishEye / Crucible	Crowd	Clover	plugin.testrunner.version	Platform Version	Groovy version
8.9.2	pom	8.5.11	7.1.2	6.7.5	8.0.4	4.8.7-20210224094345	5.1.2	3.1.7	2.0.2	5.0.0	-
8.10.4	pom	8.5.11	7.1.2	6.7.5	8.0.4	4.8.7-20210224094345	5.1.2	3.1.7	2.0.3	5.0.32	-
8.11.2	pom	9.11.0-QR-20230802122956	7.1.2	6.7.5	8.0.4	4.8.7-20210224094345	5.1.5	3.1.7	2.0.3	5.0.32	-
8.12.4	pom	9.11.0-QR-20230802122956	8.6.1	6.7.5	9.2.7	4.9.0-20230919145634	5.2.2	3.1.7	2.0.4	5.0.32	4.0.12
8.13.5	pom	9.11.0-QR-20230802122956	8.6.1	6.7.5	9.2.7	4.9.0-20230919145634	5.2.2	3.1.7	2.0.4	5.0.32	4.0.12
8.14.3	pom	9.11.0-QR-20230802122956	8.6.1	6.7.5	9.2.11	4.9.0-20230919145634	5.2.2	3.1.7	2.0.5	5.0.32	4.0.19
8.15.4	pom	9.11.0-QR-20230802122956	8.6.1	6.7.5	9.2.11	4.9.0-20230919145634	5.2.2	3.1.7	2.0.5	6.0.42	4.0.19
8.16.0	pom	9.11.0-QR-20230802122956	8.6.1	6.7.5	9.2.11	4.9.0-20230919145634	5.2.2	3.1.7	2.0.5	6.0.42	4.0.19
8.17.1	pom	9.11.0-QR-20230802122956	8.6.1	6.7.5	9.2.11	4.9.0-20230919145634	5.2.2	3.1.7	2.0.5	6.0.42	4.0.19

Note 1: AMPS 8.14.3+ requires Atlassian Plugin SDK to 8.2.10, because the previous versions of the SDK have errors with Maven and generating effective POM. More info on this matter is here: Bamboo Data Center 10.0 Early Access Program release - #7 by sopel.

Note 2: Don’t blindly upgrade Atlassian Plugin SDK to the highest versions. Always check compatible versions of your products in the SDK release description.

Note 3: Sometimes upgrade affects testing tools. So, after upgrading AMPS or SDK always check not only that atlas-mvn _product_:run works but in addition that:

Wired integration tests run with atlas-mvn _product_:remote-test
Web tests (functional, accetpance, e2e) run with atlas-mvn _product_:integration-test

P.S.
I wish you all less tinkering with dependency management and more valuable results for your business.

mkemp · August 20, 2024, 9:41am

I’ll respond in full when I have time. Please do create a new thread and/or Jira issue in the AMPS project for every new problem you discover with AMPS. We also take PRs, but don’t feel required to.

I’ve fixed this, apologies, it was a mistake.

mkemp · August 30, 2024, 2:03pm

I’ve finally had a free slot, thanks for reporting the issues you’ve discovered. I’ll pass this all on to the team that owns AMPS and the SDK.

Yes, the team looking after AMPS and the SDK has decided to give a few more modern versions compared to what used to be very old. As part of that that, they’ve done it as .tar.gz only and are updating the documentation on how to install the SDK to reflect that. Apologies, I don’t think they’ve announced their plans, I’ll follow up with them to do that.

All of them except below should be there from AMPS 8.11.1

                --add-opens=java.base/sun.nio.cs=ALL-UNNAMED
                --add-opens=java.base/java.nio.charset=ALL-UNNAMED
                --add-opens=java.base/java.lang.ref=ALL-UNNAMED

Could you please say which Jira version and which pages don’t work without these? I can’t see any mention of these internally to figure out why they’re needed? They might not be.

Our apologies, the latest version of Dev Toolbox should work in all supported versions of all products. We’ve updated the latest versions of AMPS to use the latest version of Dev Toolbox and other tools by default.

FWIW, if you ever run into issues with dev tools, they can be changed in the AMPS configuration by setting quickReloadVersion, devToolboxVersion, achooVersion, pluginViewerVersion, pdeVersion, and webConsoleVersion. I’ll ask the team to update the documentation to show what’s not already there.

Please only use those properties as a last resort, we’d prefer everyone relies on the default versions provided by AMPS so we can rollout bugfixes easily.

For a long time the SDK versions exactly matched the AMPS versions and bundled the appropriate Maven version. This should’ve been better communicated, sorry about that. We did this in our early days to make it as easy as possible, with time, we now think it’s a mistake because it’s lead to situations like this.

Going forward, you can use the ATLAS_MVN environment variable to use a version of Maven that is not bundled with the SDK. It’s almost always worth updating Maven too, there’s been quite a few show stopping bugs in Maven 3.

Please do regularly schedule upgrades to AMPS. We’re constantly fixing and improving things. If you have any issues please do create a new thread reporting the issue and/or a Jira ticket so we can fix it.

This is good advice, we run these in our CI which is how we catch these issues when we upgrade AMPS in our plugins internally.

The latest version of AMPS and the dev tools should always work with all the supported product versions.

ViacheslavDobromyslo · August 31, 2024, 2:50am

Thank you, @mkemp ! I will give a try to all the provided tips-and-tricks to make the last AMPS work with the last Jira+Confluence LTS. I have a platform of 10+ plugins with Wired and Web tests to check against.

I made a unified plugin platform with sets of common and product-specific plugins for Jira 9.12.x LTS and Confluence 8.5.x LTS. And it works fine with AMPS 8.11.2 + SDK 8.2.10.

Also, what can you tell about SDK 9.0.2? I see in the Compatibility section that it support only the latest versions:

Jira Data Center 9.17.1
Confluence Data Center 9.0.1

Is it backward-compatible with LTSes?

UPD: SDK 9.0.2 does not work because of the following error:

[INFO] Artifact jndi:jndi:pom:1.2.1 is present in the local repository, but cached from a remote repository ID that is unavailable in current build context, verifying that is downloadable from ...
...
Failed to read artifact descriptor for jndi:jndi:jar:1.2.1
Caused by: The following artifacts could not be resolved: jndi:jndi:pom:1.2.1 (present, but unavailable): Could not transfer artifact jndi:jndi:pom:1.2.1 from/to tmatesoft (https://maven.tmatesoft.com/content/repositories/releases/): status code: 403, reason phrase: Forbidden (403)

Workaround is here:

There was a support request filed a few days ago in this topic:

ViacheslavDobromyslo · August 31, 2024, 10:39am

Regarding the Atlassian Developer Toolbox developer-toolbox-plugin-3.0.6.jar and developer-toolbox-plugin-3.1.0.jar .

I tried to run them in Jira 9.12.12 LTS and got the following error during startup:

2024-08-31 12:51:40,836+0300 main ERROR      [c.a.plugin.manager.DefaultPluginManager] There was an error loading the descriptor 'developer-toolbox.name-jira' of plugin 'com.atlassian.devrel.developer-toolbox-plugin'. Disabling.
java.lang.RuntimeException: Unable to enable web fragment
	at com.atlassian.plugin.web.descriptors.AbstractWebFragmentModuleDescriptor.enabled(AbstractWebFragmentModuleDescriptor.java:114)
...
Caused by: com.atlassian.plugin.PluginParseException: Unable to load the module's display conditions: Could not load 'com.atlassian.jira.plugin.webfragment.conditions.UserIsAdminCondition' in plugin com.atlassian.devrel.developer-toolbox-plugin
	at com.atlassian.plugin.web.descriptors.ConditionElementParser.makeConditionImplementation(ConditionElementParser.java:84)
...
Caused by: com.atlassian.plugin.web.conditions.ConditionLoadingException: Could not load 'com.atlassian.jira.plugin.webfragment.conditions.UserIsAdminCondition' in plugin com.atlassian.devrel.developer-toolbox-plugin
	at com.atlassian.jira.plugin.webfragment.JiraWebFragmentHelper.loadCondition(JiraWebFragmentHelper.java:44)
...
Caused by: java.lang.ClassNotFoundException: com.atlassian.jira.plugin.webfragment.conditions.UserIsAdminCondition not found by com.atlassian.devrel.developer-toolbox-plugin [35]

I tried to downgrade the plugin to:

3.0.5 - does not work.
3.0.4 - does not work.
3.0.3 - works.

So, I still don’t recommend blindly upgrading AMPS to the latest version if you use Jira/Confluence LTS. When upgrading you should understand how it works and tinker with AMPS <devToolboxVersion>3.0.3</devToolboxVersion> configuration parameter.

And I think there should be an additional branch of AMPS and other tools compatible with the latest LTS versions of the Atlassian products… Otherwise, configuring the build tools takes more time than developing valuable features in our plugins.

ViacheslavDobromyslo · September 1, 2024, 2:23pm

Thanks to @mkemp , Finally, I configured the working plugin toolset for Jira 9.12.x LTS and Confluence 8.5.x LTS and all wired+web-integration tests passed.

How to do it:

Install Atlassian SDK 9.0.2 from Atlassian Marketplace.
Comment out unavailable tmatesoft repository in atlassian-plugin-sdk-9.0.2/apache-maven-3.9.8/conf/settings.xml. See details.
Don’t use the default DevToolbox:
- Jira 9.12.x LTS works only with the old developer-toolbox-plugin-3.0.3. Newer versions 3.0.4+ fail to start up and throw error mentioned in my previous comment.
- Confluence 8.5.x LTS works fine even with the latest developer-toolbox-plugin-3.1.0
Configure your dependencies and plugins like in the following example:

<properties>
    <jira.version>9.12.12</jira.version>
    <confluence.version>8.5.11</confluence.version>
    <amps.version>8.17.1</amps.version>
    <jiraDevToolboxVersion>3.0.3</jiraDevToolboxVersion>
    <confluenceDevToolboxVersion>3.1.0</confluenceDevToolboxVersion>
    
    <atlassian-plugins-osgi-bridge.version>7.1.9</atlassian-plugins-osgi-bridge.version>
    <osgi.javaconfig.version>0.6.0</osgi.javaconfig.version>
    <jsr311api.version>1.1.1</jsr311api.version>
    <jackson.version>1.9.14-atlassian-6</jackson.version>
    <testrunner.version>2.0.5</testrunner.version>
    <junit.version>4.13.2</junit.version>
    <felix.version>7.0.5</felix.version>
    <spring.version>5.3.34</spring.version>
    <gson.version>2.10.1</gson.version>

    <!-- Java 17 workaround for some Maven plugins -->
    <!-- See for details: https://confluence.atlassian.com/jiracore/java-17-runtime-opens-and- exports-arguments-1188413810.html -->
    <jvm17.opens />
</properties>

<dependencies>
    <!-- Spring Java Config -->
    <dependency>
        <groupId>com.atlassian.plugins</groupId>
        <artifactId>atlassian-plugins-osgi-javaconfig</artifactId>
        <version>${osgi.javaconfig.version}</version>
    </dependency>
    <dependency>
        <groupId>org.apache.felix</groupId>
        <artifactId>org.apache.felix.framework</artifactId>
        <version>${felix.version}</version>
        <scope>provided</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-beans</artifactId>
        <version>${spring.version}</version>
        <scope>provided</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>${spring.version}</version>
        <scope>provided</scope>
    </dependency>
    
    <dependency>
        <groupId>com.atlassian.plugins</groupId>
        <artifactId>atlassian-plugins-osgi-bridge</artifactId>
        <version>${atlassian-plugins-osgi-bridge.version}</version>
        <scope>provided</scope>
    </dependency>

    <!-- TestRunner -->
    <dependency>
        <groupId>com.atlassian.plugins</groupId>
        <artifactId>atlassian-plugins-osgi-testrunner</artifactId>
        <version>${testrunner.version}</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>javax.ws.rs</groupId>
        <artifactId>jsr311-api</artifactId>
        <version>${jsr311api.version}</version>
        <scope>provided</scope>
    </dependency>
    <dependency>
        <groupId>com.google.code.gson</groupId>
        <artifactId>gson</artifactId>
        <version>${gson.version}</version>
        <scope>provided</scope>
    </dependency>

    <!-- Testing -->
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>${junit.version}</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-test</artifactId>
        <version>${spring.version}</version>
        <scope>test</scope>
    </dependency>
</dependencies>

<build>
  <pluginManagement>
    <!-- Add it only to your plugin for Jira pom file-->
    <plugin>
      <groupId>com.atlassian.maven.plugins</groupId>
      <artifactId>jira-maven-plugin</artifactId>
      <version>${amps.version}</version>
        <extensions>true</extensions>
        <configuration>
          <devToolboxVersion>${jiraDevToolboxVersion}</devToolboxVersion>
          ...
        </configuration>
    </plugin>
    <!-- Add it only to your plugin for Confluence pom file -->
    <plugin>
      <groupId>com.atlassian.maven.plugins</groupId>
      <artifactId>confluence-maven-plugin</artifactId>
      <version>${amps.version}</version>
        <extensions>true</extensions>
        <configuration>
          <devToolboxVersion>${confluenceDevToolboxVersion}</devToolboxVersion>
          ...
        </configuration>
    </plugin>
  </pluginManagement>
</build>

<profiles>
    <!-- Java 17 workaround for some Maven plugins -->
    <!-- See for details: https://confluence.atlassian.com/jiracore/java-17-runtime-opens-and-exports-arguments-1188413810.html -->
    <profile>
        <id>jvm17</id>
        <activation>
            <jdk>17</jdk>
        </activation>
        <properties>
            <jvm17.opens>
                --add-opens=java.base/sun.nio.cs=ALL-UNNAMED
                --add-opens=java.base/java.nio.charset=ALL-UNNAMED
                --add-opens=java.base/java.lang.ref=ALL-UNNAMED
                --add-opens=java.base/java.lang=ALL-UNNAMED
                --add-opens=java.base/java.lang.reflect=ALL-UNNAMED
                --add-opens=java.base/java.util=ALL-UNNAMED
                --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED
                --add-opens=java.base/java.io=ALL-UNNAMED
                --add-opens=java.management/javax.management=ALL-UNNAMED
                --add-opens=java.desktop/sun.font=ALL-UNNAMED
                --add-opens=java.base/sun.reflect.generics.parser=ALL-UNNAMED
                --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED
                --add-opens=java.base/java.time=ALL-UNNAMED
                --add-exports=java.base/sun.util.calendar=ALL-UNNAMED
                --add-exports=java.base/sun.security.action=ALL-UNNAMED
                --add-exports=java.xml/jdk.xml.internal=ALL-UNNAMED
            </jvm17.opens>
        </properties>
        <build>
            <pluginManagement>
                <plugins>
                    <!-- Workaround to avoid InaccessibleObjectException when running `integration-test` and `remote-test` in console -->
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-failsafe-plugin</artifactId>
                        <version>2.22.2</version>
                        <configuration>
                            <argLine>${jvm17.opens}</argLine>
                        </configuration>
                    </plugin>
                </plugins>
            </pluginManagement>
        </build>
    </profile>
</profiles>

P.S. Java 17 workaround is still needed to open --add-opens=java.base/java.lang=ALL-UNNAMED and possibly some other packages for atlas-mvn _product_:remote-test.

mkemp · September 3, 2024, 3:41pm

Thanks, I’ve fixed this in Developer Toolbox 3.1.1 and should be released with AMPS 9.0.7

Here’s the Jira issue [DEVBOX-59] - Ecosystem Jira

We are trying to keep things simple by having the latest version of each of our tools supporting all of our supported product versions. This specific issue affected all versions of Jira.

I’ve responded in the original thread, thanks again for reporting this.

KonradGarus1 · September 11, 2024, 7:01am

@mkemp Where should we be downloading the SDK from? I see release notes for 9.1.1 at https://developer.atlassian.com/server/framework/atlassian-sdk/amps-9-1-1/.

Meanwhile, the Marketplace is at 9.0.2 for TGZ and only 8.2.7 for Mac/DEB/RPM/Windows.

mkemp · September 11, 2024, 4:22pm

We used to release SDK and AMPS together. AMPS can be upgraded in the pom.xml of a plugin without updating the SDK. Similarly running with -u <version> (e.g. atlas-version -u 9.1.1) will use a later version of AMPS even thought the SDK version is older. The SDK consists of;

Maven
Shell scripts
A specific version of AMPS

It’s safe to use a newer version of AMPS with an older version of the SDK.

It’s safe to use a newer version of Maven with the SDK and AMPS