For jogamp artifacts, we currently [manually articulate all platforms for jogamp components](https://github.com/scijava/pom-scijava/blob/pom-scijava-35.1.1/pom.xml#L5714-L5893) in the `<dependencyManagement>` section—e.g.: ```xml <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](https://github.com/scijava/pom-scijava/blob/pom-scijava-35.1.1/pom.xml#L2033-L2036): ```xml <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](https://github.com/scijava/pom-scijava/blob/pom-scijava-35.1.1/pom.xml#L5269-L5340), 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).