Not all plugins in the Gradle ecosystem are compatible with each other. However, Gradle doesn’t provide APIs to address this use case neatly. It’s also rare for plugins to state the extent of their compatibility across existing and future plugins. It isn’t practical to build a compatibility matrix for all the plugins in existence. For this reason, we provide the following compatibility guidelines. Working around those compatibility guidelines will result in undefined behaviours. As much as possible, we try to enforce those guidelines by providing actionable error messages. For example, we display the following error message when using software model plugins with dev.nokee.jni-library plugin:

Nokee detected the usage of incompatible plugins in the project ':'.
We recommend taking the following action:
 * Use 'dev.nokee.objective-cpp-language' plugin instead of the 'objective-cpp' and 'objective-cpp-lang' plugins [1][2]

To learn more, visit

[1] To learn more about 'dev.nokee.objective-cpp-language' plugin, visit
[2] To learn more about software model migration, visit

For a more in-depth understanding of the plugin identification convention used by Nokee and the capability dimensions, read the Anatomy of Nokee Plugins chapter.

Use only one main entry point capability per project

As a general rule of thumb, each project should only have one main entry point capability. The application and library are well-known entry points. It is crucial to stress that plugins add capabilities to a project. Composing capabilities is a different concern and is solved differently. It doesn’t mean Nokee will never allow multi-entry-point projects. It means plugins already specifying an entry point are incompatible with each other. For example, dev.nokee.cpp-application and dev.nokee.c-application are incompatible as both provide the application entry point, which is unlikely to use the same modelling. Similarly, dev.nokee.cpp-application and dev.nokee.cpp-library are also incompatible as both provide an entry point as well, that is, application and library respectively. Alternatively, dev.nokee.jni-library and dev.nokee.cpp-language are compatible as one plugin provides an entry point, e.g. library, while the other plugin provides an implementation language.

Avoid software model plugins

The software model plugins are in the process of being phased out. For this reason alone, we should avoid the software model plugins. See the migrating from software model chapter to learn more.

Use language plugins when composing implementation language capabilities

Plugins that allow additional implementation language, such as dev.nokee.jni-library, should use the language only plugins. For example, use dev.nokee.cpp-language instead of dev.nokee.cpp-application.