RFCs are a way for Atlassian to share what we’re working on with our valued developer community.
It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.
Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!
- Publish : 18th March 2024
- Discuss : 2nd April 2024
- Resolve : 15th April 2024
Summary of Project:
Atlassian is assessing the most effective method to supply partners and third-party developers with the necessary libraries for developing solutions against our products. We are proposing to no longer provide combined third-party/atlassian repositories. This change primarily impacts our maven-external repository. We are seeking input from the community as to possible solutions.
Problem
Security and Trust are core to Atlassian. We have identified opportunities to improve and optimise how we deliver Artifacts, maven and otherwise, to third party developers. Our current approach delivers internal and external artifacts within combined repositories. We have identified that this isn’t congruent to industry norms where cross-repositories dependencies from organisation such as ourselves are acceptable and would like to provide end users with transparency regarding the source of libraries. Also we have not maintained the level of availability we would like to achieve with our current solution. We are therefore looking for feedback on how we can simply the delivery of artifacts to our customers.
Proposed Solution
We are currently proposing to remove third party repositories and therefore any packages which they contain from our publically available repositories located at packages.atlassian.com. Partners and developers would therefore need to fetch dependencies directly from maven central, spring, typesafe, sonatype and other third party repositories. We are aware of the impact that a sudden and uncoordinated change such as this would cause to our partners.
The solution would therefore maintain or enhance:-
- Previous, current and Upcoming versions of Atlassian Libraries.
- Atlassian specific patches for third-party software, such as the Atlassian version of a patched log4j.
- Clear documentation on the location of third-party software.
- Recommendations to use Artifact Management Solutions.
- Updates to Atlassian produced tooling and build files such as poms.
Asks
While we would appreciate any reactions you have to this RFC (even if it’s simply giving it a supportive “Agree, no serious flaws”), we’re especially interested in learning more about how our partners use our public repositories, your concerns around this change and ideas for making any transition as smooth as possible.
1 Like
I already use my own package and artifact manager where I simply added the Atlassian maven external repo.
For me this change would be a win, since it makes it easier to maintain the different repos Marvelution uses. In the past I needed to reorder my repos since the artifact form Atlassian was not matching that of other repos resulting in build errors.
However, for those that don’t have a artifact manager in please, this will be a pain to setup and manage, especially in the timespan is short.
In both cases it really helps if a list of repos is published where Atlassian gets its dependencies from.
3 Likes
Hi @AlistairBush
I tried to remove this :
<repository>
<id>atlassian-public</id>
<url>https://packages.atlassian.com/mvn/maven-external/</url>
<snapshots>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
<checksumPolicy>warn</checksumPolicy>
</snapshots>
<releases>
<enabled>true</enabled>
<checksumPolicy>warn</checksumPolicy>
</releases>
</repository>
</repositories>
But unfortunately, when i build my app in local…
Unresolveable build extension: Plugin com.atlassian.maven.plugins:jira-maven-plugin:8.0.2 or one of its dependencies could not be resolved: Failed to read artifact descriptor for com.atlassian.maven.plugins:jira-maven-plugin:jar:8.0.2: Could not transfer artifact com.atlassian.maven.plugins:jira-maven-plugin:pom:8.0.2 from/to atlassian-plugin-sdk (file://${env.ATLAS_HOME}/repository): Repository path /repository does not exist, and cannot be created.
I think for us is not just removing repositories from our projects…
We detect impact for Development with Atlassian SDK 8.2.8 and to build app for production.
1 Like
Whatever Atlassian decides to do here, please make sure that it is coordinated with plenty of advance notice, that you update the default build tooling to work with the new configuration, and that you provide examples of how to transition from the legacy configuration to the new setup.
This probably means releasing a new version of the Plugin SDK and/or AMPS (which are already broken for Platform 7 and in need of update anyway, as previously mentioned), as well as creating a page on DAC (not buried in a thread on the community forum) that describes the needed steps for a classical Maven project.
6 Likes
Hi Fabien.
Sorry if I didn’t make it clear in the RFC. We will still be providing the maven-external repository and packages such as com.atlassian.maven.plugins:jira-maven-plugin will still be available at that location.
What the RFC proposes is that any dependencies. for example junit or com.fasterxml.jackson would not be available at maven-external. Instead you would need to ensure that maven central is enabled in your repository settings.
2 Likes
Okay thanks for the precision 
So, I don’t really understand the difference with RFC-24 : Platform 7 with Grey api removal
To enable the removal of the third-party dependencies listed above, we had to ensure they were no longer used in the public API. This means we’ve made changes to the public API of many Atlassian components to decouple them from these third-party dependencies. In some cases, we’ve used the opportunity to consolidate or further restrict the public API where we believe viable alternatives exist. Here’s the full list:
Hi @FabienPenchenat
I will try to shed more light on the differences between this RFC and our announcement about Platform 7.
In Platform 7 we announced we are removing certain 3rd party libraries from DC and our API. It means that the code won’t be available for plugins at runtime, unless they copy the library in their own jar.
RFC-42 states that our infrastructure (Atlassian hosted Maven repository) no longer will be providing access to external artifacts. They will need to be downloaded from “Maven central” or any other standard location. That change influence the compilation of plugins.
3 Likes
Thanks again for this precision.
From our side this RFC will be quite easy to process but thank you for warning.
This is very much appreciated and thank you also for your quick responses.
Fabien
Hello everyone,
I believe that in our case, for the Projectrak and Exporter apps, we won’t have much trouble incorporating such dependencies and get them from Maven Central.
However, as mentioned in a previous message, it would be helpful if a list of repositories from which Atlassian obtains its dependencies were published.
One concern I have is that currently, during the app installation process, there are often many errors, and it sometimes requires multiple attempts. I’m not sure if increasing the size of the Apps’ Jars will also increase the problems during installation.
Best regards, and thank you.