Using plugin from composite build

Help/Discuss
1

Hi,

I am trying to use a local gradle plugin (lets call it sample-plugin) in another gradle project (call it consumer) without having to change the settings.gradle file of either. I am already able to get it work by using includeBuild (my-plugin) in the consumer project or by passing the command line flag to include build. But not able use plugin if I create a composite build as either a parent project or sibling project to both consumer and plugin projects.

To demonstrate the problem, I have create the following GitHub repository with all the three variations. I have kept files to bare minimum to just focus on the problem statement.

It contains three directories :

  1. direct-include - consumer directly includes it by changing its own settings.gradle file
  2. parent-composite - tries to include the plugin via a parent composite project (without having to change consumer)
  3. sibling-composite - tries to include the plugin via a sibling composite project (without having to change consumer)

When I run them

  1. gradle -p direct-include/consumer sayHello (works)
  2. gradle -p parent-composite :consumer:sayHello (doesn’t work)
  3. gradle -p sibling-composite/composite :consumer:sayHello (doesn’t work)

The case number 2 & 3 fail with following (which essentially means the dependency was not substituted in these build)

Plugin [id: 'org.sample.greeting', version: '1.0-SNAPSHOT'] was not found in any of the following sources:

What am I trying to achieve with this:
Being able to substitute plugin dependency for local debugging without changing both plugin and consumer projects (since i have quite many of them and updating each consumers settings.gradle is undesirable here just to debug)

So, any help in fixing case 2 & 3 is highly appreciated.

2

To fix both parent and sibling, include the plugin before the consumer in the composite’s settings.gradle.

diff --git a/parent-composite/settings.gradle b/parent-composite/settings.gradle
index 492ae70..f519783 100644
--- a/parent-composite/settings.gradle
+++ b/parent-composite/settings.gradle
@@ -1,4 +1,4 @@
 rootProject.name = 'parent-composite'

+includeBuild('sample-plugin')
 includeBuild('consumer')
-includeBuild('sample-plugin')
\ No newline at end of file
diff --git a/sibling-composite/composite/settings.gradle b/sibling-composite/composite/settings.gradle
index 891fa47..b595b7b 100644
--- a/sibling-composite/composite/settings.gradle
+++ b/sibling-composite/composite/settings.gradle
@@ -1,4 +1,4 @@
 rootProject.name = 'composite'

+includeBuild('../sample-plugin')
 includeBuild('../consumer')
-includeBuild('../sample-plugin')
\ No newline at end of file
1 Like
3

Thanks for the help.

It makes sense now, however, I expected gradle to form a DAG and resolve dependencies without depending on order of declaration. hopefully future versions won’t depend on ordering.

Thanks again :slight_smile:

4

I had similar expectations.

5

It’s probably not that trivial, because included builds are not built just because they are included. They are only configured and built if they are actually used. To be order independent you would need to at least configure all builds but you also cannot configure them if the needed plugins are not available yet, …

6

To be clear, I think it’s fine the way it is, I just remember falling into this trap myself when I first started using composites. Gradle’s been too helpful over the years and we’ve all grown accustomed to these things automatically working out :slight_smile:

7

yeah, I echo the same sentiment without a doubt .