Recommended technique for grouping projects in multi-project build

Old Forum Archive
1

Hi,

I fear I may be misusing multi-project builds, but I currently have the following structure for a Java project:

/
      build.gradle
      core/
        build.gradle
      plugins/
        build.gradle
        plugin a/
        plugin b/

I have bundled the plugins into a grouping ‘plugins’ project solely because all plugins share certain build dependencies and tasks. There is no Java code in this project, and nor should there be any other artifacts.

The problem with this is, of course, that ‘plugins’ is treated by Gradle as a project in its own right rather than a grouping mechanism. This means that, say, if the ‘jar’ target is run for the whole multi-project, a skeletal ‘plugins.jar’ is created.

This is liveable, just a bit confusing.

Is there a recommended way to have shared configuration for a selected group of sub-projects? Are n-deep projects advised against?

2

This is because you are applying the Java plugin to the plugins project. If you don’t apply any plugins to it then it will have no tasks.

3

Thanks Luke; I did fear as much. Both the plugins and core are Java projects, so I declared the Java plugin at the root level (along with other config which is to be shared with all projects). It would be nice if there was a notion of a ‘configuration project’ - i.e., something which provides shared configuration its children but doesn’t produce artifacts. I may just have to flatten the structure.

4

There are ways of avoiding applying plugins…

allprojects {
  if (project.name == "plugins") {
    return
  }
  apply plugin: "java"
}
5

Nice, that works. Thanks!