Jira-maven-plugin: Cannot resolve javax.transaction:jta:jar:1.0.1B

Jira Development Jira Data Center
1

Hey community,

If I try to start Jira through the jira-maven-plugin, I get this Maven error:
[ERROR] Failed to execute goal com.atlassian.maven.plugins:jira-maven-plugin:9.1.1:run (default-cli) on project jira-helloworld: Cannot resolve javax.transaction:jta:jar:1.0.1B:compile: exceptions = []; missing artifacts = [javax.transaction:jta:jar:1.0.1B:compile] -> [Help 1]

Is anyone else experiencing this? It happens also if I create a plain new project like described in the docs.
Seems to be related to Why can't I download the javax.transaction:jta:1.0.1B JAR? - Documentation and https://jira.atlassian.com/browse/JRASERVER-43031.

Just wondering if someone found a good solution for this.

1 Like
2

Hey @AndreasRutzK15t,
AFAIK the javax.transaction:jta:jar:1.0.1B artifact is located in the Atlassian SDK directory, but looks like the SDK 9.1.1 does not look up for artifacts inside itself. Try to add its repository explicitly, hope it will help you.

In your project folder in pom.xml add additional repository:

<project ...>
    <repositories>
            ...

        <repository>
            <id>atlassian-plugin-sdk</id>
            <url>file://${env.ATLAS_HOME}/repository</url>
            <snapshots>
                <enabled>true</enabled>
            </snapshots>
            <releases>
                <enabled>true</enabled>
                <checksumPolicy>warn</checksumPolicy>
            </releases>
        </repository>

Probably, it also makes sense to specify the same as an additional <pluginRepository>

1 Like
3

Hi Team,

Please make sure you’ve reviewed these two pages to ensure your configurations are correct for atlas-mvn and related tools

If you have a custom settings.xml please check the details. Also ensure you’re using the Platform POM as well and for Jira, that you’re using jira-api and not jira-core.

James.

4

How does this work when building for backwards compatibility (i.e. any version prior to Platform 7)?

1 Like
5

Hi @remie,

I have to put my flame proof pants on here and say, as far as I know, it doesn’t. Platform 7 is a hard boundary. You can do something in the code and maven to allow for -P profiles, but you’ll end up with 2 artefacts: one for earlier versions and ones for Platform 7.

James.

6

Hey thanks for your help. Adding the Atlassian SDK to the list of repositories solves the problem. But since we have a more complex setup and don’t want to install Atlassian SDK everywhere, we ended up adding jta to our private Maven repo. That’s a bit easier to setup in our case but still not ideal tbh.

7

Hi @jrichards

Since this monday (2024-11-18) we have this error during build step:

Failed to collect dependencies at com.atlassian.jira:jira-core:jar:9.12.0 -> com.octo.captcha:jcaptcha:jar:2.0-alpha-1: Failed to read artifact descriptor for com.octo.captcha:jcaptcha:jar:2.0-alpha-1: The following artifacts could not be resolved: com.octo.captcha:jcaptcha:pom:2.0-alpha-1 (absent): Could not transfer artifact com.octo.captcha:jcaptcha:pom:2.0-alpha-1 from/to maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for repositories: [maven-public.codebarrel.io (http://maven-public.codebarrel.io.s3-website-us-east-1.amazonaws.com/public, default, releases+snapshots)] -> [Help 1]

We haven’t changed anything but obviously something has changed in version 9.12.0 of jira-core :slightly_frowning_face:

any idea why?

8

Hi @FabienPenchenat,

I did a mvn dependency:tree and didn’t see com.octo.captcha:jcaptcha:jar:2.0-alpha-1 in my simple Hello, World example build for Jira 9.12.0. But I’m using jira-api not jira-core. jira-core isn’t recommended or supported. It’s found when I use jira-core, but then I see jndi:jndi:jar:1.2.1 is not found.

I’m following up internally about the ownership of that maven repo, but can you make sure you’ve got your settings.xml configured based on these pages

And use jira-api.

James.

9

Hello @FabienPenchenat,

See also this comment

James.

10

I still find this statement confusing @jrichards, because there are dozens of product versions prior to Platform 7 that still depend on jira-core. It may not be supported or recommended for Platform 7+ starting with Jira 10, but every version prior to Jira 10 will still have it and we will still be building against it.

So if somebody says “I’m building against Jira 9.12 with jira-core and it’s not working” this is a valid question and concern, as we are supposed to be still supporting Jira 9.12 given that it’s an LTS release with an of life date of 29 November 2025

2 Likes
11

We have both, jira-core and jira-api.
For jcaptcha, i found the solution, i just remove this block on the pom.xml

        <repository>
            <id>maven-public.codebarrel.io</id>
            <url>http://maven-public.codebarrel.io.s3-website-us-east-1.amazonaws.com/public</url>
        </repository>

I have now a problem with jta but we can solve it with this link (third-party-libraries) :+1:

12

It has come to my attention that versions of Jira-core/Jira-api that were already released are being impacted by changes introduced in early October. This situation is highly problematic, as it goes against the principle that released versions should remain immutable.

Additionally, the information regarding these changes is scattered across various platforms like Slack, the Atlassian Community, and developer.atlassian.com. This fragmentation makes it increasingly difficult to track and understand what is happening.

And as @remie said, jira-core 9.12.0 is actually the more recent LTS :point_right: Atlassian support EOL

13

Hi,

I’m referring not to the Product Jira Core, but the library for development:

In Jira 5.0, we separated the Java components that we consider to be part of our API from the internal components that are subject to change without notice.

The API components live in a Maven module called jira-api.

Apps can depend on this module that means that they will use only the safe Jira components.

<dependency>
    <groupId>com.atlassian.jira</groupId>
    <artifactId>jira-api</artifactId>
    <version>${atlassian.product.version}</version>
    <scope>provided</scope>
</dependency>

James.

14

And I’m referring to the fact that over the course of more than a decade, Atlassian has shipped documentation still telling app developers to use jira-core, to use add the product pom to dependency management like this

            <dependencyManagement>
                <dependencies>
                    <dependency>
                        <groupId>com.atlassian.jira</groupId>
                        <artifactId>jira-core</artifactId>
                        <version>${jira.version}</version>
                        <type>pom</type>
                        <scope>import</scope>
                    </dependency>
                </dependencies>
            </dependencyManagement>

and even ship a direct dependency to jira-core as part of the maven archetype for apps used by atlas-create-jira-plugin.

The core premise of dependency management is that it is immutable. Once published, packages should be considered sacred. You can’t remove them. You can’t update them. This is it.

There are thousands of consumers of jira-core and its transitive dependencies. And when Atlassian took on the burden to create an SDK that Just Works :tm:, it also took on the burden of providing access to all packages in the entire dependency chain.

And when Atlassian decided to fork 3rd party libraries and Frankenstein them, Atlassian took on the burden of providing access to these packages.

This one is on you Atlassian, not us. Do not break the sacred oath shared by anyone ever involved in dependency management.

2 Likes
15

Hi @FabienPenchenat,

I checked with engineering and the codebarrel repo isn’t used any more. All the required artifacts should be picked up by using the latest settings.xml I mentioned, or using the latest atlas-* tools.

James.

1 Like