Which AMPS version to use?

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?

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

1 Like

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:


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

1 Like

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:


This library has this in pom.xml:


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? :slight_smile: 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?

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.

1 Like

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.


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.

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.)

1 Like

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.