Best Practices for Organizing Build Logic

Old Forum Archive
1

When developing custom classes & plugins, there are many options to choose from as described in the user guide. Are there any best practices anyone would like to share?

In my case, I need to write stuff that will be shared across hundreds of modules that span several product lines.

  • Sometimes, all I need to do is to tweak conventions created by other plugins. Creating a plugin just for this seems like a lot of overhead, but it does give me the ability to version it. I could have everyone “apply from” a static location, but versioning would be trickier.
  • When I create new tasks & conventions, I’ve struggled choosing between buildSrc, multi-project, and independent modules sharing a common repo.
    • I wanted unit tests for my build, but I found JUnit style tests to be very hard to write and maintain for the plugin. I’m very tempted to drop them altogether in favor of a multi-project build where subprojects are my unit tests.
    • buildSrc seems convenient, but the build lifecycle confuses me and I get tired of having the build process the directory when running unit tests.
2

Hey,

You’ve touched a big topic here :slight_smile: Here’re my thoughts:

  1. It’s useful to share a plugin even if it only tweaks some conventions. This way you drive consistency in the organisation. Also it gives you a place where conventions can grow and evolve into more advanced plugins. 2. I mainly use buildSrc as a sandbox for rapid plugin prototyping. I want the plugins versioned and shared more easily so pretty soon I elevate buildSrc into a proper gradle project. 3. M7 brings improvements around init scripts: http://wiki.gradle.org/display/GRADLE/Gradle+1.0-milestone-7+Release+Notes#Gradle1.0-milestone-7ReleaseNotes-Initscriptimprovements This should enable easier sharing of your corporate/enterprise plugins. 4. Putting all tests in a separate subproject in the hierarchy is one of the approaches to integration testing. Since integ tests usually have different classpath and somewhat different lifecycle many times we don’t want them to stick in the same place as unit tests. Another option in gradle for integration tests is to use a separate sourceSet for integ tests. This is a useful approach if you have a multi-project build with lots of subprojects and you don’t want to proliferate subprojects to accommodate integ tests. Otherwise, a separate subproject for integ test is a fine approach.

Hope that helps!