Limit subproject task search

Given a root project with 3 java subprojects A, B, C

when someone runs “./gradlew build” from the root project directory I want it to run B:build and C:build but NOT A:build. Is there any way to control that?

Programmatically? No.
That’s the sense of a task name without project path.
It runs the task in all projects where it exists.
When calling you could add -x :A:build, or you could provide a buildRelevant lifecycle task that depends on build from B and C and tell people to use that instead.

Figured as I couldn’t find anything. IntelliJ’s built-in “build” button seems to run just “build” from project root - trying to customize that behavior a bit if you have any other ideas.

I know I can customize and tell gradle exactly what to run from command-line and from custom IntelliJ run configurations - but we have developers who by default just push that button, and trying to get that to work well for them. {
    doFirst {
        check(!project.hasProperty("")) {
            "Do not use the 'build' button from IntelliJ ;-P"


Maybe a bit more friendly: {
    if (project.hasProperty("")) {

Interesting approaches… took your ideas and adjusted a little. In the projects I want skipped on a “global” task I added this:

  gradle.startParameter.taskNames.forEach { taskName ->
    if (taskName != "clean" && !taskName.contains(":")) {
      val taskProvider = tasks.findNamed(taskName)
      if (taskProvider != null) {
        val task = taskProvider.get()
        task.enabled = false

As we transition from ant to gradle we have a library we are building, that is inside the same git repo, that takes 10 mins to build. For normal developers they refer to it as a simple maven artifact, and don’t need the “build” task in those subprojects to trigger when they press the build button in IntelliJ

Eventually we will move the library to a separate repo, but have to maintain ant and gradle support concurrently during our transition.

But point well taken.

That it is inside the same repository does not mean it needs to be within the same Gradle build.
You can as well have a totally separate independent build for that library.
And for those developing that library, you could add a switch to included it as composite build, so only those get it automatically builded freshly if necessary.

I was thinking of a -Pxxx property that would determine which included projects to load in settings.gradle. Is that something like what you are suggesting?

If you mean with includeBuild, not include, then yes.
Because the lib sounds like it should be an extra standalone build.
And if you include the whole build via composite build feature you also do not need to change the dependency by coordinates as it will be automatically substituted by the included build if you do not do bad things like jar name or coordinate manipulations and even then you could mitigate that with manual substitution rules.

I have everything in one big include(…) list in settings.gradle. Guess I need to learn about difference between include() and includeBuild() - never used the later before. Thanks for all the help.

1 Like