Manage native classifier artifacts consistently: all platforms? or current platform only?

[ctrueden]

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

[ctrueden]

Given the fact that Gradle does not properly resolve these profile-triggered property values when pom-scijava is used as a platform, I think "all platforms always" is probably a better bet, since it is more explicit and reduces reliance on profile activation.