Apply plugin in .gradle file imported through apply from

Old Forum Archive
1

In an effort to split up our gradle configuration into smaller pieces, we have several gradle files that are imported in the main build.gradle file.

I.e

apply from: "a.gradle"
apply from: "b.gradle"
apply from: "c.gradle"

We are using gradle 2.2

When we apply a plugin within a.gradle, like this:

apply plugin: 'some.plugin'
  task myTask(type: com.x.y.z.MyTask) {
  // configure task
}

This fails with an error: “Could not find property ‘com’ on root project”

The same error occurs even if we do apply plugin in the build.gradle file before applying a.gradle. However, it works if we put the task definition in the build.gradle file. Note that we have a buildscript section that imports our custom plugin as a classpath dependency.

Is this as expected?

2

I dug into the ssh-gradle-plugin since I can use the SshTask in a.gradle and see that they do the following in a Convention class:

// Inside the convention class
  // Alias to omit import in build script
final Class SshTask = org.hidetake.gradle.ssh.plugin.SshTask

// Inside the SshPlugin.apply(Project project)
  project.convention.plugins.ssh = new Convention(project)

This led me to try the following, which works.

// build.gradle
  apply plugin: 'some plugin'
  project.ext.MyTask = com.x.y.z.MyTask

and then in a.gradle:

// a.gradle
task myTask(type: MyTask) {
  }

Obviously I would not want to set all classes in my plugin manually onto the project.ext object.

Is the gradle-ssh-plugin use of the convention setting to make the task class available the way to go for plugins if you want to use plugins in gradle files such as a.gradle?

3

There’s not much difference between the two approaches.

4

Is using conventions in plugins a good idea? According to this post, we shouldn’t use conventions any more.

5

They haven’t been deprecated yet, but they will be at some point. It’s unlikely we’ll remove them before Gradle 4. They may become deprecated in Gradle 3 though.

6

Ok, thanks for the reply.

So, given that:

  • I do not want to use a deprectated feature like conventions * I do not want to manually set project.ext.properties to class references, i.e project.ext.MyTask = com.x.y.z.MyTask

how would I go about defining tasks in gradle files that are included in build.gradle through “apply from:” (i.e like a.gradle in my example above) when I want to extend a Task class that is defined in a plugin?

// a.gradle
  task myTask(type: com.x.y.z.MyTask) {
  }