Specify classifiers instead of using os detection in netty-all

[candrews]

Motivation:
The OS used to build netty-all is irrelevant to the system using netty-all.

The build environment's OS should not impact the dependencies of netty-all. The OS used to build netty-all is irrelevant to the system using netty-all at runtime. So instead of using os-maven-plugin via the jni.classifiers property to set dependency classifiers, set the correct classifiers explicitly.

Modification:
Set classifiers of the dependencies in netty-all.

Result:

Fixes #11272
See #8097

[normanmaurer]

@candrews I think this will not work... as for example on linux you will still enable the linux profile when depending on netty-all and so the native dns resolver for macOS will not be included. Which means when you build on linux but deploy to Mac you will run into issues imho... the same is true for building on macOS but deploy to linux

[normanmaurer]

basically netty-all should "pull in" all native dependencies no matter on which system your run and build (that was how it behaved before)

[njhill]

@normanmaurer I don't follow your reasoning, the changes look right to me. If you are building with linux profile it must mean you are targeting linux for deployment, at least that's what I infer from the comments in the pom:

    <!-- The linux profile will only include the native jar for epol to the all jar.
         If you want to also include the native jar for kqueue use -Puber.
    -->

I agree that in general it would be best to just use the uber profile so that the resulting artifacts can be deployed anywhere and work with the appropriate native libs in each case.

[normanmaurer]

@njhill the problem is that the profiles will be included in the pom that is deployed and so automatically activated based on the system you are pulling the dependency in

[njhill]

@normanmaurer ok I see what you mean. The changes in this PR are still "correct" just orthogonal to the problem you're describing.

Again the way the comments are worded in the pom, it sounds like the profiles are intended to be set/specified based on a target deployment environment rather than activated based on the detected build environment. If that's not correct and the profile is set based on the detected OS at build time, then it's wrong to have this profile separation in the netty-all pom at all and we should just get rid of the OS-specific (non-uber) profiles. This would essentially match the old behaviour more closely too, because the profile never came into the picture when consuming the pre-built uber jar.

[candrews]

It seems to me that all the profiles should be removed.

• all native dependencies should be just dependencies and not specified inside of a profile
• Since there's no code, the coverage and full profiles are no-ops so they can be removed

The problem with this change is that it results in dependencies for platforms other than the one being built cannot be found. For example, when I build on my Linux system, netty-all fails to build with this error:

[ERROR] Failed to execute goal on project netty-all: Could not resolve dependencies for project io.netty:netty-all:jar:4.1.65.Final-SNAPSHOT: The following artifacts could not be resolved: io.netty:netty-transport-native-kqueue:jar:osx-x86_64:4.1.65.Final-SNAPSHOT, io.netty:netty-resolver-dns-native-macos:jar:osx-x86_64:4.1.65.Final-SNAPSHOT: io.netty:netty-transport-native-kqueue:jar:osx-x86_64:4.1.65.Final-SNAPSHOT was not found in https://oss.sonatype.org/content/repositories/snapshots during a previous attempt. This failure was cached in the local repository and resolution is not reattempted until the update interval of sonatype-nexus-snapshots has elapsed or updates are forced -> [Help 1]

Which of course makes sense. If it could build, the result would be correct - but I'm not sure how to get it to build.

I've updated this PR with this change so hopefully someone else can suggest a way forward.

[candrews]

I'm looking at .github/workflow and expected to see where the osx packages get built, but I'm not seeing anything. How does that work?

[candrews]

@chrisvest reading #9689 (comment) it sounds like netty uses something other than GitHub Actions to build the MacOS native libraries. How does that work?

I'm guessing a similar solution is currently in place for Windows, too, based on #11284

[chrisvest]

@candrews I don't know how the MacOS builds work, exactly. Just that they aren't GitHub Actions.

[normanmaurer]

This can be closed now with #11732 in