Search Gradle plugins

Version 0.2.6 (latest)

Created 03 October 2015.

Extension to gradle native plugins

This plugin extends the gradle plugins for native code, it adds the following
- Copy shared libraries depenencies with apu linkage as part of executable
- Add pre/post compile tasks
- Add pre/post link tasks
- Add pre/post install tasks

- Requires gradle version 2.6
- For the pluing to work correctly the shared library and executable must have
the same variants

0.2.6 Beta release patch 5
- Add support for custom source sets in a binaries scope.

0.2.5 Beta release patch 5
- Fix an issue that cause pre/post compile/link taks to ignore googl test
executable compile/link

0.2.4 Beta release 2 patch 4
- Fix an issue with copy library dependency task where a directory was created
in the install task output instead of copying the library

0.2.3 Beta release 2 patch 3
- Fix an issue that caused the copy library dependency tasks to not execute
when the component name had capital letters.

0.2.2 Beta release 2 patch 2
- Add support for google test executables - google test executables are treated
as normal executables

0.2.1 Beta release 2 patch 1
- Fix an issue that prevent using the native extension plugin with the
google-test plugin
- Minor documentation fix

0.2.0 Beta release 2
- Remove copy library dependency for shared linkage, since it's handled by
the native plugin

0.1.1 Beta release patch 1
- Minor fix to plugin description

0.1.0 Beta release

0.0.0 Development test

Build script snippet for plugins DSL for Gradle 2.1 and later:

plugins {
  id "com.xykivo.nativeextension" version "0.2.6"

Build script snippet for use in older Gradle versions or where dynamic configuration is required:

buildscript {
  repositories {
    maven {
      url ""
  dependencies {
    classpath ""

apply plugin: "com.xykivo.nativeextension"


The new way to add plugins to a project is much more than a more convenient syntax. The new DSL is processed very differently to the old one. The new mechanism allows Gradle to determine the plugins in use very early and very quickly. This allows Gradle to do smart things such as:

  • Optimize the loading and reuse of plugin classes.
  • Allow different plugins to use different versions of dependencies.
  • Provide editors detailed information about the potential properties and values in the buildscript for editing assistance.

This requires that plugins be specified in a way that Gradle can easily and quickly extract, before executing the rest of the build script. It also requires that the definition of plugins to use be somewhat static.

There are some key differences between the new plugin mechanism and the “traditional” apply() method mechanism. There are also some constraints, some of which are temporary limitations while the mechanism is still being developed and some are inherent to the new approach.

Constrained syntax.

The new plugins {} block does not support arbitrary Groovy code. It is constrained, in order to be idempotent (produce the same result every time) and side effect free (safe for Gradle to execute at any time).

The form is:

plugins {
    id «plugin id» version «plugin version»

Where «plugin version» and «plugin id» must be constant, literal, strings. No other statements are allowed; their presence will cause a compilation error.

The plugins {} block must also be a top level statement in the buildscript. It cannot be nested inside another construct (e.g. an if-statement or for-loop).

Can only be used in build scripts.

The plugins {} block can currently only be used in a project's build script. It cannot be used in script plugins, the settings.gradle file or init scripts.

Future versions of Gradle will remove this restriction.

Cannot be used in conjunction with subprojects {}, allprojects {} etc.

It is not possible to use the familiar pattern of applying a plugin to multiple projects at once using subprojects {} etc. at the moment. There is currently no mechanism for applying a plugin to multiple projects at once. At the moment, each project that requires a plugin must declare so in the plugins {} block in its buildscript.

Future versions of Gradle will remove this restriction.

If the current limitations of the new plugin mechanism are problematic for your build, the recommended approach is to use the “traditional” mechanism for the time being.