Classpath Container update on synchronization

buildship
eclipse

(Pascal Wölfle) #1

Hello everyone,

at our company, we successfully migrated to the new Buildship 2.0 plugin and we are very happy with it.

But we have the effect, that on each synchronization (“Refresh Gradle Project”) an incremental build is triggered. After debugging, I found out that these builds are caused by project description modifications.

These project description modifications are caused by the GradleClasspathContainerUpdater#updateFromModel() method, which sets the Gradle classpath container on each synchronization, although there are no changes. Eclipse automatically touch the project on which the classpath container is applied.

Is it necessary to set the classpath container again, although there are no changes?

I print out the stacktrace, when the touch happen:

Stacktrace

java.lang.Exception
at org.eclipse.core.internal.resources.Project.touch(Project.java:1297)
at org.eclipse.jdt.internal.core.SetContainerOperation.executeOperation(SetContainerOperation.java:115)
at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:724)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2240)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2267)
at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:795)
at org.eclipse.jdt.core.JavaCore.setClasspathContainer(JavaCore.java:5591)
at org.eclipse.buildship.core.workspace.internal.GradleClasspathContainerUpdater.setClasspathContainer(GradleClasspathContainerUpdater.java:161)
at org.eclipse.buildship.core.workspace.internal.GradleClasspathContainerUpdater.updateClasspathContainer(GradleClasspathContainerUpdater.java:75)
at org.eclipse.buildship.core.workspace.internal.GradleClasspathContainerUpdater.updateFromModel(GradleClasspathContainerUpdater.java:127)
at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.synchronizeJavaProjectInTransaction(SynchronizeGradleBuildOperation.java:237)
at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.access$200(SynchronizeGradleBuildOperation.java:106)
at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation$4.run(SynchronizeGradleBuildOperation.java:223)
at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:39)
at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:724)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2240)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2267)
at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:5521)
at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:5478)
at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.synchronizeJavaProject(SynchronizeGradleBuildOperation.java:219)
at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.synchronizeOpenWorkspaceProject(SynchronizeGradleBuildOperation.java:214)
at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.synchronizeWorkspaceProject(SynchronizeGradleBuildOperation.java:189)
at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.synchronizeGradleProjectWithWorkspaceProject(SynchronizeGradleBuildOperation.java:179)
at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.access$000(SynchronizeGradleBuildOperation.java:106)
at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation$1.run(SynchronizeGradleBuildOperation.java:141)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2240)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2262)
at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.synchronizeProjectsWithWorkspace(SynchronizeGradleBuildOperation.java:138)
at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.run(SynchronizeGradleBuildOperation.java:122)
at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildsJob.synchronizeBuild(SynchronizeGradleBuildsJob.java:77)
at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildsJob.runToolingApiJob(SynchronizeGradleBuildsJob.java:68)
at org.eclipse.buildship.core.util.progress.ToolingApiJob$1.run(ToolingApiJob.java:73)
at org.eclipse.buildship.core.util.progress.ToolingApiInvoker.invoke(ToolingApiInvoker.java:62)
at org.eclipse.buildship.core.util.progress.ToolingApiJob.run(ToolingApiJob.java:70)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)


(Stefan Oehme) #2

Not strictly, but making a deep comparison is expensive and adds more complexity to the code. JDT detects that nothing has changed and shouldn’t recompile anything. That’s why we didn’t consider this a problem so far.

Is this a performance problem for your project? If yes, could you elaborate what is taking long on the incremental build?


(Pascal Wölfle) #3

Eclipse internal compares the old classpath container with the new one via equals (see org.eclipse.jdt.internal.core.SetContainerOperation.executeOperation() line 84 in Eclipse Neon).

Therefore the org.eclipse.buildship.core.workspace.internal.DefaultGradleClasspathContainer must override the equals-method, mustn’t it?


(Pascal Wölfle) #4

Our project has about 300 sub-project and the pain is that the resource delta is calculated on each project and builder when the incremental build is running. Actually, no builder is creating something. So the incremental build is unnecessary and wast 1-2min of time :wink:


(Stefan Oehme) #5

It could, though that would only do something if the underlying IClasspathEntry implementations have proper equals/hashCode as well. If they do, then this is an easy win.


(Pascal Wölfle) #6

Would you accept a contribution via pull request? This would fix two issues for us :slight_smile:


(Stefan Oehme) #7

Of course, contributions are welcome :slight_smile:


(Pascal Wölfle) #8

Pull Request created: https://github.com/eclipse/buildship/pull/369