From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

Can I use the `org.gradle.nativeplatform.OperatingSystemFamily` attributes for publishing JARs that should only be selected on specific operating systems? Or are these purely for native development artifacts?

Currently it should be the best way, yes. 
See also <https://github.com/gradle/gradle/issues/34845|https://github.com/gradle/gradle/issues/34845>

Note that right now a consumer build needs to do _something_ for the selection. I.e. the standard Java plugins do not have an opinion (like selecting the current OS as default). There are plugins helping with this. E.g.:
• <https://github.com/mvnpm/gradle-native-java-plugin/|github.com/mvnpm/gradle-native-java-plugin>
• <https://github.com/gradlex-org/java-module-packaging|github.com/gradlex-org/java-module-packaging>
• <https://github.com/openjfx/javafx-gradle-plugin|github.com/openjfx/javafx-gradle-plugin>
Or consumers need to directly define attributes.

As I mentioned in the linked issue, it would be nice to consolidate that into some standard solution on the long run.

<@U023HSZL88M> I think it gets a bit more complicated if a plugin requires this.

What I mean that if a plugin might behave slightly differently depending on an OS because it might need an additional JAR, that resolution might need to be dealt with in settings.gradle. (OR in the old way by manipulaing buildscript.classpath)

Yes that's an interesting case I haven't had  yet. I think for plugins the attributes would need to be configured on `buildscript { configurations { classpath { } } }` . If the plugins are "loaded" in settings already. Otherwise probably also on `buildscript...`  of the corresponding project. I don't think there is another place this could be done.
Maybe this would be an interesting addition for the `gradle-native-java-plugin` . The author – <https://github.com/ia3andy|github.com/ia3andy> / <@U09PY36LMBJ> I believe – created that plugin in response to the issue linked above (see comment there). He is probably open for a contribution in this area.

I'm not sure whether one could manipulate the build.gradle `buildscript.configurations.classpath` from the settings.gradle `pluginManagement` . That would have been ideal as one could then apply a settings plugin.

~I would sure like to know as I could not find configuration manipulation - only plugin id and version manipulation~

Never mind. I found it. It is directly on `Settings` and not inside the `pluginManagement` block

Yes that's confusing. It would be great if that part would be added to `pluginManagement`  as well at some point. Maybe then `buildscript` could be deprecated on the long run. That would probably clarify things.

I did some tests trying to manipulate `classpath` inside Settings, but ran into
```   &gt; Cannot change attributes of configuration 'classpath' after it has been locked for mutation```

I finally came up with a solution that works. by using the `getGradle().getLifecycle()` .

I made a new PR which <@U09PY36LMBJ> can take if he wants. <https://github.com/mvnpm/gradle-native-java-plugin/pull/3|github.com/mvnpm/gradle-native-java-plugin/pull/3>