Configuration 'diplugin' not found on configuration container inside the Test class

Hi,

I’m writing a gradle plugin and in the apply method I have the next code (let’s call it “MyFirstPlugin.groovy”):

void apply(Project project) {
  project.configurations{
    diplugin{
      transitive = false
    }
  }
      /* SOME MORE CODE */
      project.dependencies{
    /* the some.group.in.here is just an example */
    diplugin group: 'some.group.in.here', name: 'MyName', version: '1.0.0+', ext: 'txt'
  }
      /* AGAIN MORE CODE*/
      /*Then I have this code where the exception raises*/
  project.configurations.diplugin.each { file ->
    project.copy {
    from file
      into workDir
      rename(/SomeName.*txt/, 'SomeName.txt')
    }
  }
}

Then, I have - in the test folder - the file MyFirstTest.groovy with the next code

@Test
  public void checkTasks() {
    Project project = ProjectBuilder.builder().build()
      project.apply plugin: 'MyFirstPlugin'
     //
<- Exception raise here!
     /* More and more code */
    }

So, with the code above, When I run the build I get the next exception:

groovy.lang.MissingPropertyException: Could not find property 'diplugin' on configuration container.

As I mentioned before, the stacktrace shows the error in the line << project.configurations.diplugin.each … … … … >>

If I catch the exception with a try-catch I can successfully pass the build, everything works nice and the exception never raises - it only raises in the test class but never in a real scenario, which means that the configuration is not present in the test!

Does anyone know how can I make configurations available in the test class? The try-catch does not seem an alternative since I should need to include in the test class the test for configurations.

Thanks in advance!

P.S. Note that I’m not declaring the dependencies in the build.gradle file but inside the code of the plugin.

‘ProjectBuilder’ can be used only for very simple cases. It won’t cut it if you need to deal with configurations and resolving dependencies. There’s nothing built-in for integration testing builds and plugins (though this has been on the roadmap for very long time now) so I would suggest you have a look at Nebula Test plugin’s ‘IntegrationSpec’. Nebula is a set of open source gradle plugins provided and maintained by guys at Netflix. It will require that you use Spock to drive your test but there is nothing stopping you from using the abstractions they created to write a base JUnit test with the same functionality as the base Spock spec they provide.

Thanks for your answer Marcin!

I ran some tests, the code in my test class is the next:

@Test
  public void checkTasks() {
    Project project = ProjectBuilder.builder().build()
        project.configurations{
      myCustomConf{
        transitive = false
      }
    }
          project.apply plugin: 'MyFirstPlugin'
     //
I just catched the exception temporally to pass this segment
         println "Collectin' configurations in test"
    project.configurations.collect{
       println it
    }
    println "End of configurations collecting in test"
  }

The result is

Starting the test
11:31:20.984 [Test worker] DEBUG o.g.a.i.a.m.DefaultLocalMavenRepositoryLocator - No local repository in Settings file defined. Using default path: /home/myuser/.m2/repository
Applying Plugin
Exception while collecting the dependencies
  //Because the catch
Collecting configurations in test
 configuration ':myCustomConf'
End of configurations collecting in test

So, it seems like ProjectBuilder is able to load configurations if I define them in the test class but not from the plugin. Then, a question comes to me: Is it a problem with the plugin I’m actually writing or is it just a the problem you mentioned?

I suppose that the problem is that I’m declaring the configurations inside the plugin - I mean, in the apply method. Declaring configurations - as in the case of the test - outside the plugin it’s like having a build.gradle file.

Seems like the project instance is not being passed to the plugin or something similar.

Forget the last comment. It’s wrong since a wrong commit overwrote a class and resulted in that behavior.