Hi, all
I have the current project setup:
RootProject A
– Plugin Project B
– Project C that uses the plugin project B
From the current searches, the “best” solution is to have 2 separate projects instead of this one project A:
RootProject A1
– Plugin Project B
RootProject A2
– Project C that uses B
Is this correct? Isn’t it possible to directly use the project B as base for the project C?
Currently there is no better way than separating them. This will change with composite builds, scheduled for Gradle 3.1 Then you will be able to develop a plugin and its consumer together.
Is plugin B something you cannot place in buildSrc for some reason?
Hi, Chris,
if I am not mistaken, no: I want a clear “border” between the two projects where C is using B “in a normal and usual way”. Simply said: this is for unit-testing plugins.
With 3.1, as mentioned above, this ability should be here so I will give it a try.
Thx all
Fair enough. I got the impression that you would prefer to keep the projects grouped, which is why I suggested buildSrc. If only one project is ever going to use the plugin, then you can save yourself the overhead of managing separate projects and binary sharing.
As for composite builds, in my opinion they are just a developer tool and not intended for use in project organization. In other words, I would never commit composite builds to source control. If projects are that coupled I would just put them into one project since they don’t really have separate lifecycles anymore. Perhaps the Gradle team sees otherwise, @st_oehme?
I’m curious what you meant by “this is for unit-testing plugins”? Plugins should be unit-tested with TestKit.
If the plugin is only used by Project C, then @Chris_Dore is right: It can just be in buildSrc, you don’t need to wait for composite builds.
Composite builds will also be useful for breaking up mono-repos into chunks that can be worked on individually or together. So there will be both: Composites that you just do ad-hoc and composite that you check in.
For multi-repo setups (which is what we’re using) I understand the ad-hoc use case where it may be beneficial for a developer to checkout and work on multiple projects simultaneously. I don’t see where composite builds would fit as a committed piece of source code. I guess it could be an intermediate step between mono and multi-repos, is that perhaps what you are thinking of?
Imagine you have a mono-repo and you want to stick with that. But often you just work on one sub-component. You can avoid the overhead of all the other projects (up-to-date checks, modules in IDEA etc.) by modeling your mono-repo as a composite made up of smaller builds.
buildSrc will also become an implicit included build, it already behaves very much like composite builds do. At one point it might be completely removed. Users can then just name their plugin build whatever they want or even have multiple ones. You can include it in the main build and have an even smoother transition from “internal plugin” to “deployed plugin”.
I see, I misunderstood what you meant by breaking up mono-repos. Seems like you’re describing the “elastic-deps” type of use case. Right now, unless I missed something, the composite build settings look very static. Is there plans to make that more dynamic, where it can automatically detect which sub-components are available in source form? Or maybe it already does that, I’ll admit I haven’t actually tried it yet, mostly because I’m trapped on much older versions of Gradle…and I don’t want to find something I love too much but can’t use 
includeBuild() is just a plain old method in settings.gradle, so you can surround it with any conditions you like, e.g. if(someFolder.exists())....
I’m afraid we have just that for you
OK, I had this in mind too but thought there could be plans to make it a part of the core functionality. Even if “plans” means a nice to have wishlist item.
@lexxy23, sorry for somewhat hijacking your thread. Hopefully you find this extra information useful as well.
I don’t know what you mean, it is part of the core functionality. Just have a look at the composite build user guide chapter.
No problem ^^ I enjoy all your responses as that I can learn from them, too.