I have multiple Eclipse projects all under the same workspace belonging to the same topic. Some provide libs only, some frontends for the web browser etc., therefore some of the projects depend on each other and those dependencies are modeled within Eclipse.
The current approach is to migrate those to Gradle with each of the former projects being one independent build. Dependencies between projects/build are modeled using composite builds, by adding
includeBuild(../some_project) into whichever project needs that kind of dependency. Reason is that Gradle supports composite builds in general and this seems to be the closest what has been used before. Additionally, this makes it easy to change an included project and test the changes in the including project without the need to first publish the included project to some internal repo or such.
Building those projects on the shell works somewhat well, not so in Eclipse Buildship: The task view contains each and every individual build multiple times. Additionally, operations like adding a Gradle nature to individual builds/Eclipse projects takes a very long time. Looking at the progress bar it seems that each and every entry in what can be seen in the task view is processed multiple times. I can see multiple repeated project names in the bar, most likely because a project includes a project which itself includes another project again and so on. I’ve encountered multiple additional problems with composite builds in the past as well already.
Running into problems with composite builds again and looking at the Buildship-related issues not being resolved, makes me wonder if to use composite builds at all? Is anyone using those actually for non-trivial setups and with integration in IDEs like Eclipse? I’m already using the most current version of Eclipse 2019-12 and Buildship I guess.
Or is the best approach to consider composite builds in Gradle as being broken and to avoid them? But what are the alternatives then? Always publishing changes of projects to some internal repo before being able to test them? This sounds very complicated and would be far easier with not using Gradle at all and staying with Eclipse-only projects instead.
The docs about composite builds could be read like one should create new builds implementing the composite of projects only, without any further development in the composite itself. Does that improve things? In my setup that would mean that I need to create one additional composite-build for lots of projects and that individual projects actually containing code couldn’t be build ever. Doesn’t make too much sense as well.
So, I’m interested in your advice regarding how to use composite builds, if at all. thanks!