4

I am developing a custom plugin that I want to be able to deploy to a repository at a later stage so I've created a stand alone module for it.

Before I do any formal TDD on it, I wanna do certain exploratory tests manually so, I've created a demo module that uses the given plugin in.

The only way I've found so far to do this was to deploy the plugin into a local repository and then import it on the other module. But this is very tedious and it's quite easy to forget to deploy it.

I was wondering if there is a way to do this more straight forward.

pablisco
  • 14,027
  • 4
  • 48
  • 70

2 Answers2

6

Update(2020-09-07):

It's possible to use includeBuild("plugin/module") to add a module into the classpath of the project so the plugin can be applied. With one caveat, it doesn't work yet if you want to apply it on settings.gradle[.kts] as I found out on this thread.

Old answer:

The best solution I've found was to include the folders of the plugin module as part of the buildSrc module (used for local scripting) within it's source sets like:

sourceSets {
    main {
        groovy.srcDirs += "../custom-plugin/src/main/groovy"
        resources.srcDirs += "../custom-plugin/src/main/resources"
    }
}

This will let you use the plugin as if it was in the remote repository but without having to deploy it every time. Next unit tests :)

pablisco
  • 14,027
  • 4
  • 48
  • 70
3

Option 1:

If you are using gradle 3.1 or later, you can use the composite build feature. Build your standalone module like this: gradle build --include-build /path/to/plugin-root

Assuming you run this command from the root of a standalone gradle project that applies the plugin, this would first build the plugin, then build your standalone project and apply the just built plugin to it.

Option 2:

If you use an older gradle version (which does not support composite builds), you can apply the maven plugin to your plugin project. This defines the install task, which you can now call by running gradle install in the root of your plugin project. This task builds your plugin and puts the resulting jar in a local cache directory (on Linux the default path is ~/.m2). Notice that after every change you make in the plugin code, you have to run gradle install again.

Now, for your standalone project to use the local plugin jar, you need to edit the build script and put mavenLocal() under buildscript.repositories. Make sure that mavenLocal() is above anything else in the repositories block.

Example of the buildscript block of your standalone project:

buildscript {
    repositories {
        mavenLocal()
        maven {
            url "https://plugins.gradle.org/m2/"
        }
    }
    dependencies {
        classpath "com.mycompany.plugins:my-awsome-plugin:1.0.0"
    }
}
Doron Gold
  • 3,664
  • 4
  • 32
  • 44
  • Option 2 is what I mentioned on my question that I was trying to avoid. And Option 1 seems like almost as much trouble. :( Thanks though. – pablisco Feb 17 '17 at 12:46
  • I don't see why option 1 seems like almost as much trouble. It is actually a huge improvement. You don't have to `install` the plugin anymore after every change. All you have to do is add a single parameter to the `gradle build` command of the demo module. I personally feel that after I started using the composite-build feature while developing a plugin, I am able to see the results of my changes much faster and my life is generally much better :) – Doron Gold Feb 17 '17 at 21:34
  • Sorry, i meant against what I suggested on my answer – pablisco Feb 18 '17 at 19:24