For jogamp artifacts, we currently manually articulate all platforms for jogamp components in the <dependencyManagement> section—e.g.:

<dependency>
	<groupId>org.jogamp.gluegen</groupId>
	<artifactId>gluegen-rt</artifactId>
	<version>${org.jogamp.gluegen.gluegen-rt.version}</version>
	<classifier>natives-android-aarch64</classifier>
</dependency>

Even though we have nice properties defined for use downstream:

<scijava.natives.classifier.gluegen>${scijava.natives.classifier.jogamp}</scijava.natives.classifier.gluegen>
<scijava.natives.classifier.joal>${scijava.natives.classifier.jogamp}</scijava.natives.classifier.joal>
<scijava.natives.classifier.jocl>${scijava.natives.classifier.jogamp}</scijava.natives.classifier.jocl>
<scijava.natives.classifier.jogl>${scijava.natives.classifier.jogamp}</scijava.natives.classifier.jogl>

I don't remember for sure, but I might have done this because regardless of platform, we still want to manage all native classifiers for downstream consumers to depend upon should they so choose. (This seems like it should be rare to me, but what do I know, maybe it's helpful for debugging sometimes to depend on the natives-linux-amd64 artifact from a Windows box?)

But regardless of whether this pattern is considered good or not, we are currently inconsistent with how we handle the javacpp component native classifiers, which are each only managed for the current platform.

We need to make a decision about which approach is best: "all platforms always" (our current approach for jogamp natives) or "current platform only" (our current approach for javacpp natives).