AMPS 8.3.x has been available since September 2021. It requires Maven 3.6.3 or later.
The most recent SDK version is 8.2.7, released in April 2021, and comes bundled with Maven 3.5.4.
This means that anyone wishing to use the latest AMPS release must separately install a newer Maven version. However the SDK documentation recommends using the bundled Maven version.
Are there any plans to release a new SDK version that supports AMPS 8.3.x out of the box any time soon? There have been no SDK releases in over a year.
Just returning to this thread to wish the Atlassian SDK v8.2.7 a very happy second birthday.
It has now been 2 years and not a single update to the SDK in all that time. v8.2.7 remains the current version.
Atlassian happily asks vendors of DC apps to retest and submit performance and scale testing results annually, but doesn’t offer those same developers any updates to the core tooling used to build and maintain said apps for over 24 months.
Sorry, I’m not posting news of a new version, but I have some workarounds;
The ATLAS_MVN environment variable can be set to a maven home directory. This could also be used with something like mvnvm if you need different versions for different projects.
As for the SDK using a newer version of AMPS (the maven plugin that does all the real work), in a maven project if the version of AMPS is set then the SDK will use that instead.
Thanks @mkemp. I do appreciate that you’re just suggesting a workaround here.
However as noted in my initial post:
Atlassian should either update the SDK (preferred), or retract their official guidance around using the bundled Maven version.
There are other impacts caused by the lack of an updated version, such as Quickreload that requires 4.0.0 or later to work on M1 macs, but the version bundled in the current SDK is 3.0.2.
Yes, I can probably workaround that too by explicitly specifying a dependency on the later quickreload version in my pom.xml
But the point is we shouldn’t need these workarounds if Atlassian cared as much about P2 developers as they do about Forge.
I understand, I’ve already raised this with the team that owns the SDK (which is actually the same team that owns AMPS). I’ve asked them to respond too, but in the meantime I found it has been on their radar, but they’ve been trying to get access to the keys to relase a new version of the SDK.
But the point is we shouldn’t need these workarounds if Atlassian cared as much about P2 developers as they do about Forge.
The department that looks after “Ecosystem” generally is basically only focused on Cloud and thus mostly Forge. Here in DC we’re all P2 plugin engineers ourselves, we feel every bump too. We still have a team dedicated to the platform modules and developer tooling.
If I’m honest with you the last two years of SBOM security work has been a huge effort, it’s slowed down everything, but it’s by far been the number one DC customer concern.
If it helps distract from some of the pain; AMPS has updated default versions of Achoo DB console, Plugin Data Editor, Dev toolbox, Plugins viewer. They now work more consistently across all products, and should be faster to startup with the products.
Is it still embarrasing we haven’t done anything with the SDK for 2 years? yes.
Please keep posting where you find pain and/or any suggestions, it helps bring focus and satisfaction to the work.
I hadn’t appreciated from your “server developer” title that you are in fact an Atlassian; so hearing this from someone on the inside is very much appreciated.
For me personally (and I can’t speak for others), when I see a reply/post from someone with “Atlassian staff” in their title, it does tend to carry more weight, and makes me pause to read it more than a post from a “Marketplace partner”, “Cloud developer”, “Expert” etc. who I might otherwise scroll past (if it’s a topic I’m not closely following).
I’m going to be real with you: nobody listens to that advice, it’s somewhat bad too because not all projects work with that version of maven. Internally everyone uses a higher version (normally near latest) to resolve bugs and get newer featuers. The advice comes from an era when we actually supported the SDK properly (I know) and there were more bugs in maven that made our lives difficult. In case you needed anymore proof, you can see that even the AMPS repo is using a newer version
Unless we start supporting the SDK again you have my advice and permission to use a newer version of maven. You can literally point to & blame me if you raise an ECOHELP.
It is ridiculous, it’s been 2.5 years since the last update. Once again I’ve passed the feedback to the right team. IMO they either need to kill it or update it instead of leaving it in limbo.
@mkemp When using ATLAS_MVN to specify an alternate Maven binary, what is your recommendation on how to properly configure the settings.xml for that alternate version?
(We’re not Maven experts, so apologies if this is a silly question).
If possible, we’d prefer to avoid relying on individual developers manually copying/pasting the pluginGroups and profile settings
from <path to bundled mvn>/conf/settings.xml
to <path to alternate mvn>/conf/settings.xml.
We fear that this could be potentially error prone, and would need to be reviewed/repeated each time we upgrade to a newer Maven version (or if Atlassian ever published a new SDK version that modifies settings.xml).
Is there a way to instruct the SDK to continue using it’s bundled settings.xml, even when ATLAS_MVN points to an alternate Maven binary?
Or can we put the Atlassian-specific config in some other global location where any Maven version would find it?
Just my 2c but out team is all using up to date maven versions rather than the old one installed with SDK by default (for support of newer Confluence versions), and we have asked them to place settings.xml in <userhome>/.m2/settings.xml which maven will pick up and doesn’t need to change with the SDK version.
We have to customize our settings.xml for some internal artifact repos, but I think in theory you could just either copy paste or link the original one that comes with the SDK into that location (assuming you don’t have any company specific settings)
Exactly like @richard.white (thanks) said. We have some company wide internal tool that sets up our package manager settings that everybody uses. For maven it updates the shared settings file in the maven home (~/.m2/settings.xml). This sets the upstream URLs to our internal mirrors and with the credientials to access them. We use the same setup for our CI pipelines too.
We do this so we can upgrade the version of maven repo by repo (can incrementally upgrade) and because we basically all use mvnvm (existed before the maven wrapper) it also means that basically everyone (you can somewhat enforce this using the maven enforcer plugin too) touching the repo is using the correct maven version to avoid weird problems (or at least we can all reproduce them).
If someone from Atlassian ever does decide to revisit the official guidance and remove the previous strong recommendation on using the bundled Maven version, it would be great to capture this advice (~/.m2/settings.xml) there, along with more explicit detail on using ATLAS_MVN to specify an alternate mvn binary.
Hey folks, just wanted to let you know that a NEW version of the SDK has been released. Right now it is only available in tar.gz format, but hey! it’s updated
