I just reimported everything with the latest Buildship 2.0 snapshot version and the latest Gradle 3.3 snapshot (as a gradle wrapper), but the composite build doesn’t work. My main project shows the subprojects as eclipse projects under the “Project and External Dependencies” library, but I also have a dependency to a completely different project in the eclipse workspace, which still shown as a jar. By the way, I reimported that other project too with the same, latest snapshot versions.
@tjarvas we no longer do a “magic composite”. You have to define a composite build and import it.
Thanks, I thought it should work by default. Using the includeBuild it works now.
However there is an issue with this solution. It is not possible to includeBuild a sub-project of another main-project. It complains that the subproject doesn’t have an own settings.gradle. So in our case, we have an utility sub-project, which we would like to use as a dependency in another main project. This cannot be modeled with the composite build rules.
I can only includeBuild a main-project dependency, which obviously not covers all the real-life cases.
You include builds, not individual projects. By including a build, all the projects inside it will be available for dependency substitution.
I have two question related to composite builds:
-
Why is it not possible to execute build task of the utility project (that is defined as a part of composite build) from the Gradle Tasks view? I was under impression that these projects are independent ones.
-
Is it possible to tell Buildship to use separate settings.gradle rather than default one (say settings-composite.gradle)? I want to preserve legacy build process but benefit from the composite builds in Eclipse.
Because this is not yet supported by Gradle. It will be in the future.
No, it is not. You can create a composite in a different directory and include both. Or you can just wrap the include in an if-condition or for-loop which only kicks in when developing locally.
Could you please tell me what could be a good if-condition to detect that we are under Eclipse?
Take a look at eclipse.ini perhaps you could check for one of the system properties in there? Or add an extra one? Eg
boolean isEclipse = System.properties.containsKey('osgi.requiredJavaVersion')
I wasn’t saying “detect that you are under Eclipse”, but “detect that you are developing locally”. You want composites to work on the command line too.
Just checking the existence of the other folder should be enough.
Hi,
I’m starting to try out Buildship 2 with gradle 3.2 and composite builds. I just have 2 questions :
- Using 3.3, what will be the difference with the 3.2 behavior, because I have :projectB which includes build of :projectA (projectA is a multi-project build) and I already have dependent sub-projects of A in B classpath using composite builds ?
- I have :projectC which includes build of :projectB which includes build of :projectA. Will the final version of Buildship support this (Buildship throws an error at the moment) or is it just pure gradle related ?
Thanks
Julien
The difference will be that:
- projectA is automatically imported when you import projectB
- projectA can also reference projectB or any other included builds
This is not supported by Gradle, so we can’t support it in Buildship either. Nested composites are definitely something we want to allow in the future
Cheers,
Stefan
Thanks a lot!
I gave it a shot with the 3.3 Nigthly. I created a separate composite build project and include what I wanted. Buildship found all the (too many) related projects and imported them like a charm.
Julien
Hi,
I’ trying to use the Buildship plugin in Eclipse and I have question.
Is it planned that Buildship will some day (prefferably in the near future) support remapping of jars to Gradle projects like it it doing the Gradle (STS) or the Maven plugin? I have the feeling that current composite support in Buildship 2.x snapshots is something little bit different what I would like to have.
We have more than 130 projects grouped to about 30 Gradle multiprojects. There are lot of dependencies between these projects. Not every developer needs to work on everything, so it is good that everyone will have imported only projects that he/she is working on and the rest will be referenced as jar dependency. Quite often it happens that you need to change something in the library project, unfortunately each time in different library. So I need to be able to import/open the library project, make the change and close the project. While the project is open I want to to have project references instead of references to jar. In that way exacly works Maven plugin for Eclipse and the Gradle STS plugin, which is unfortunately not developed anymore.
Current composite support in Buildship will not solve the situation with dynamic replacement of referenced jar with opened projects, so I’m forcet to generate with gradle the maven pom.xml and import projects as maven projects to be able to work. Do you plan to support remapping of jars to Gradle projects? I would be very pleased.
We might add a UI that allows you to compose projects in an ad-hoc fashion without modifying a settings file.
We do not plan to do workspace-wide replacement, as that would require all builds in the workspace to be in one composite. That would be slow and error prone for larger workspaces. We think it’s better to be explicit about which projects you want to combine.
The GUI would be really a must to make it usable. But try to rethink the idea that it will form the composite auto automatically if not disabled with some project properties. It works well for many years in Maven plugin for Eclipse, it works in Gradle STS, so I don’t see reason why it should cause problems in Buildship.
Maybe we will try to create some patch to have this functionality, because without that functionality none of our developers want to work with Gradle and all of them complain that we should use ant instead.
You declare a composite in groovy code so you can use custom logic to define the composite. See here for the code to determine which root folders are added to an eclipse workspace. Perhaps you could write a gradle plugin to define a composite based on an eclipse workspace
Those plugins do only a very basic “dependency replacement”, not a composite build that fully integrates the projects. It’s certainly a nice feature, but I think composite builds are a superset of that. Note that composites can be defined dynamically (if-conditions, for-loops etc.), so you can build them almost any way you could imagine. Much more flexible than just saying “put everything in the workspace into one bucket and hope for the best” 
I tend to disagree on that one, since generally you want your composites to work on the command line and in all IDEs, not just one IDE. So generally I’d prefer defining them in a settings.gradle file explicitly. But I’m certainly open to adding a UI for ad-hoc use cases. If someone is interested in contributing that, I’ll be happy to guide them through the process.
You can give your developers that functionality by writing a dynamic composite that everyone uses. As long as everyone uses a conventional checkout strcuture (e.g. all projects next to each other), that would work just fine.
Don’t you know when this feature is supposed to be implemented? This is the only thing that prevents me from switching to composite builds. As soon as all projects included in composite build are independent ones it is necessary to build them independently from time to time.
It will definitely be implemented this year, most likely in the second quarter. I don’t have a more precise plan at this point.