Platform-public-api status code: 409

Hello,
We have just detected an error with the platform-public-api dependency from the package com.atlassian.platform.dependencies.

Failed to execute goal com.atlassian.maven.plugins:jira-maven-plugin:9.1.1:validate-banned-dependencies (default-validate-banned-dependencies) on project elements-connect: Failed to obtain platform dependencies: Could no
t load artifact com.atlassian.platform.dependencies:platform-public-api:8.0.0-service-accounts-SNAPSHOT: The following artifacts could not be resolved: com.atlassian.platform.dependencies:platform-public-api:pom:8.0.0-service-ac
counts-SNAPSHOT (absent): Could not transfer artifact com.atlassian.platform.dependencies:platform-public-api:pom:8.0.0-service-accounts-SNAPSHOT from/to jenkins-releases (https://repo.jenkins-ci.org/releases/): status code: 409, reason phrase:  (409) -> [Help 1]

We checked the associated repository, and the version is indeed present : Atlassian Repository: com/atlassian/platform/dependencies/platform-public-api/8.0.0-service-accounts-SNAPSHOT/

However, this version was edited on 17/04/2025 at 12:11.

Is there a solution or any further information?

5 Likes

@MarekTokarski

Maybe you know something about this version, or could point us in the right direction?
I know you’re on the Data Center side (the good side of the Force, of course :grinning_face_with_smiling_eyes:)

Thanks a lot in advance!

same issue.
atlas-package just don’t build plugin, failing with error

1 Like

Add

<configuration>
    ...
    <skipBanningDependencies>true</skipBanningDependencies>
    ...
</configuration>

to jira-maven-plugin in pom.xml as workaround

As a workaround, we upgraded to AMPS 9.3.1:
<amps.version>9.3.1</amps.version>

The issue is still present, but the build no longer crashes.

5 Likes

Is any resolution ? We are facing a build issue and it is blocking us .

Hi @NicolasDUPRE Able to reslove the issue ? we are still facing the issue

Hi @NicolasDUPRE,

After upgrading to AMPS 9.3.1, were you able to successfully start the server with “<banningExcludes>”?
<banningExcludes>
<exclude>com.google.code.findbugs:jsr305</exclude>
…
</banningExcludes>

Please let us know. Thank you.

Hello,

After upgrading to AMPS 9.3.1 with several <banningExcludes>, including:​

<banningExcludes>
  <exclude>com.google.code.findbugs:jsr305</exclude>
 ....
</banningExcludes>

we were able to package our plugin using Maven without build failures. However, the Maven debug logs still show warnings related to the banned dependency.​

[WARNING] Failed to check for banned dependencies, skipping validation
[DEBUG] Failed to check for banned dependencies because
com.atlassian.maven.plugins.amps.PlatformDependencyProvisioningException: Could not load artifact com.atlassian.platform.dependencies:platform-public-api:8.0.0-service-accounts-SNAPSHOT
    at com.atlassian.maven.plugins.amps.PlatformDependenciesProviderImpl.loadArtifact (PlatformDependenciesProviderImpl.java:113)
    at com.atlassian.maven.plugins.amps.PlatformDependenciesProviderImpl.readSingleArtifact (PlatformDependenciesProviderImpl.java:66)
    at com.atlassian.maven.plugins.amps.PlatformDependenciesProviderImpl.getDependencies (PlatformDependenciesProviderImpl.java:58)
    at com.atlassian.maven.plugins.amps.BannedDependenciesImpl.resolveDependencies (BannedDependenciesImpl.java:102)
    at com.atlassian.maven.plugins.amps.BannedDependenciesImpl.getBannedElements (BannedDependenciesImpl.java:49)
    at com.atlassian.maven.plugins.amps.MavenGoals.validateBannedDependencies (MavenGoals.java:349)
    at com.atlassian.maven.plugins.amps.ValidateBannedDependenciesExecutor.execute (ValidateBannedDependenciesExecutor.java:52)
    at com.atlassian.maven.plugins.amps.ValidateBannedDependenciesMojo.execute (ValidateBannedDependenciesMojo.java:42)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:126)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:328)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:212)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:174)
    at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:75)
    at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:162)
    at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:903)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:280)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:203)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:77)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:569)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:255)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:201)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:361)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:314)

We have not yet tested the full impact of this on the plugin’s behaviour.

Hi @NicolasDUPRE

I’m not sure what is the main issue here, can you rephrase it? Version 8.0.0-service-accounts-SNAPSHOT isn’t our typical release and most probably may be broken. Can you explain what you want to achieve? I hope I will be able to propose other 8.0.0-XXXX version.

Thanks @FabienPenchenat for mentioning me :slight_smile:

1 Like

Facing same issue. It was working fine 24 hrs back
Any workaround?
[ERROR] Failed to execute goal com.atlassian.maven.plugins:jira-maven-plugin:9.1.1:validate-banned-dependencies (default-validate-banned-dependencies) on project agile-assist: Failed to obtain platform dependencies: Could not load artifact com.atlassian.platform.dependencies:platform-public-api:8.0.0-service-accounts-SNAPSHOT: The following artifacts could not be resolved: com.atlassian.platform.dependencies:platform-public-api:pom:8.0.0-service-accounts-SNAPSHOT (absent): Could not transfer artifact com.atlassian.platform.dependencies:platform-public-api:pom:8.0.0-service-accounts-SNAPSHOT from/to jenkins-releases (Index of releases/): status code: 409, reason phrase: (409)

Hi @MarekTokarski ,

Please find the error.

[INFO] ------------------------------------------------------------------------

[INFO] BUILD FAILURE

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 4.658 s

[INFO] Finished at: 2025-04-18T15:24:22+05:30

[INFO] ------------------------------------------------------------------------

[ERROR] Failed to execute goal on project XXXXXX: Could not collect dependencies for project com.gfh.jira.plugin:XXXXXX:atlassian-plugin:1.0.0

[ERROR] Failed to read artifact descriptor for com.atlassian.platform.dependencies:platform-public-api:jar:8.0.0-service-accounts-SNAPSHOT

[ERROR] Caused by: The following artifacts could not be resolved: com.atlassian.platform.dependencies:platform-public-api:pom:8.0.0-service-accounts-SNAPSHOT (absent): Could not transfer artifact com.atlassian.platform.dependencies:platform-public-api:pom:8.0.0-service-accounts-SNAPSHOT from/to jenkins-releases (Index of releases/): status code: 409, reason phrase: (409)

[ERROR]

[ERROR] → [Help 1]

[ERROR]

[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.

[ERROR] Re-run Maven using the -X switch to enable full debug logging.

[ERROR]

[ERROR] For more information about the errors and possible solutions, please read the following articles:

[ERROR] [Help 1] DependencyResolutionException - Apache Maven - Apache Software Foundation

We are not able to execute “atlas-run”. We are blocked by this error. Please help.

Hello @MarekTokarski,

We are encountering an issue during the packaging of our plugin. Specifically, when Maven processes the banned dependencies exclusions, the build fails with AMPS 9.1.1. To address this, we attempted to upgrade to AMPS 9.3.1, which allowed the plugin to package successfully. However, upon reviewing the debug logs, we noticed that the banned dependency error persists, albeit in debug mode, and does not cause the build to fail.

The dependency causing the error is:

com.atlassian.platform.dependencies:platform-public-api:pom:8.0.0-service-accounts-SNAPSHOT​

Interestingly, the plugin was building successfully yesterday morning with AMPS 9.1.1, but by the afternoon, the issue appeared. Upon investigation, we discovered that the problematic dependency is not directly invoked by our plugin. Further examination revealed that this dependency was modified in the Atlassian repository at 12:11 PM yesterday, which suggests a potential link between the change and the issue we’re experiencing.

Given that this dependency is not part of our plugin’s direct dependencies, we are uncertain about the appropriate course of action. Should we change something in our <banningExcludes> in our pom.xml? Which version of AMPS is impacted? Additionally, we are concerned about the potential impact of this change on our plugin’s behavior.

We appreciate any guidance or recommendations you can provide to help us resolve this issue.

1 Like

Thank you @NicolasDUPRE for detailed explanation.

The issue is related to the validation mechanism in AMPS that ensures plugins are not embedding parts of the code provided by the host products at runtime. Internally that validation uses Platform definition. AMPS tries to detect what Platform version is used in the project, but if there is none it will proceed with the latest version.

I checked our internal releases and indeed we accidentally released 8.0.0-service-accounts-SNAPSHOT​. Due to the way how Maven orders versions, it became the “latest” one. I already released new version defined in a way to ensure it will be treated as newer (8.0.0-z06-ba5b2592f). I hope the issue will be resolved now.

I’m really sorry for the inconvenience. Please note that you can also define the version explicitly in your POM. You can simply define platformVersion property that will define Platform version used to validate your dependencies.

5 Likes

Thank you @MarekTokarski for your response and for providing a detailed explanation.

We have just retried the same configuration as yesterday morning, and everything is functioning correctly on our end. The issue is resolved for us.

1 Like