Buildship - Gradle > Refresh Gradle Project speed

I’ve read in other people’s posts + responses that the refresh is fast, even for larger numbers of projects. I don’t have this experience. I have a root + 36 subs: 1 ear, 4 war, 31 jar. A refresh takes only between 10 and 12 minutes, not that many seconds as others have indicated.

It starts:
and then goes through a cycle of these 3:

Not much shows up in the Gradle Operations console. I inherited this, don’t have much Gradle experience, and would appreciate suggestions or pointers on where to start tracking this down.


The screen shots are from Buildship 3.0.0. I upgraded to 3.1.0 this morning but that did not speed things up. The messages are the same with an additional “Building parameterized model…RunClosedProjectBuildDependencies” step.

I’m running on Eclipse v2018.12.

I’m wondering if it’s Buildship or the build itself. Can you please execute the cleanEclipse eclipse tasks from the command line and see if it’s any faster? If possible, is it possible to create a build scan and share it with us (./gradlew cleanEclipse eclipse --scan)?

Running that now. Will share results when it’s finished.

It’s done. 2 issues:

  1. It runs in a little over 1 minute from the command line versus the now 16 minutes in Eclipse. After answering yes to TOS, I didn’t get any output with “Publishing build scan”… or the link with the id. This is the output from the run:
    ./gradlew cleanEclipse eclipse --scan
    Project stafftrack_ear eclipse.wtp.component.file configuration…org.gradle.plugins.ide.api.XmlFileContentMerger@5d8aa249
    stafftrack_war compileJsps:config phase: generated Java source directory: C:\Development\Repos\stafftrack-2019-07-15\stafftrack_war_applicant\build\jsp-src
    Project stafftrack_ear eclipse.wtp.component.file.beforeMerged …WtpComponent{wbModuleEntries=, deployName=‘null’, contextPath=‘null’}
    Project stafftrack_ear eclipse.wtp.component.file.whenMerged…
    Project stafftrack_ear eclipse.wtp.component.file.withXML…

Publishing a build scan to requires accepting the Gradle Terms of Service defined at Do you accept these terms? [yes, no] yes

I’ve poked around but haven’t found any suggestions to cure build scans not uploading.

  1. Buildship doesn’t run all the methods in eclipse.wtp.component.file. From the command line, I get println output but when I run Gradle > Refresh Gradle Project, it get only the file println from this:
apply plugin: 'ear'
apply plugin: 'eclipse-wtp'

eclipse {
	wtp {
		component {
			file { wtpComp ->
				println "Project $ eclipse.wtp.component.file configuration..." + wtpComp
				libConfigurations += [ configurations.earlib ]

				withXml { theXml ->
					println "Project $ eclipse.wtp.component.file.withXML..." 

				beforeMerged  { beforeMergedComp ->
					println "Project $ eclipse.wtp.component.file.beforeMerged ..." + beforeMergedComp

				whenMerged { whenMergedComp ->
					println "Project $ eclipse.wtp.component.file.whenMerged..."

The withXml, beforeMerged, & whenMerged don’t print anything from inside Eclipse.

…sorry, forgot to quote my samples…

It’s hard to debug without knowing the code, and not having build scans certainly makes it harder to investigate.

You mentioned you inherited this project. What Gradle version do you use? If it’s an outdated one, I’d suggest to try updating to a more recent version.

I’m using Gradle 5.6.2 and Buildship 3.1.2. Is there any debugging we can turn on in Buildship?

Not at the moment, no. But I’m inclined to do that: add tracing to track synchronization performance.
In the meanwhile, I suggest to create a sample project which I could analyze. Can you try to minimize your projet by incrementally removing sources/subprojects/dependencies/configuration/etc and check how it affects the synchronization performance? If it’s in a shareable state then I’m happy to have a look.