Is there a way to get more detailed logging output from the Eclipse platform or the Buildship plugin (or even through the Gradle API itself) with regards to what caused a project to be rebuilt?
We are currently migrating from Eclipse Mars (with Spring Gradle plugin) to Eclipse Photon (with Gradle Buildship plugin). One problem we encounter with the new version is that it ends up rebuilding large parts of the workspace every time we open Eclipse, which may take several minutes in large projects. Refresh workspace on startup is disabled in the Eclipse preferences. Setting Max simultaneous project builds to a higher value and Max iterations when building with cycles to a lower value than the defaults help mitigate the problem a bit by speeding up that initial rebuilt, but in the end it only works around the actual issue.
We did not have these problems in the old version and this behavior seems weird to me. After fully building the workspace, closing Eclipse and reopening it, I would expect that no resources changed and there is no need for a rebuild.
While we do have quite a few custom Gradle plugins and tasks, there are no obvious offenders, like tasks that generate sources. I do not want to fully dismiss the possibility that something we customized is messing with a file while evaluating the Gradle projects, though.
Hence why getting more information about why the IDE/plugin believes that the project requires rebuilding would be really appreciated to get a starting lead.
The only setting I've found so far is eclipse.log.level, but that already defaults to ALL.
I ended up adding an .options file with
org.eclipse.jdt.core/debug=true
org.eclipse.jdt.core/debug/javadelta=true
org.eclipse.core.resources/build/delta=true
org.eclipse.core.resources/refresh=true
to the installation directory of Eclipse. Then I launched Eclipse with the -debug -consoleLog arguments. Basically as pointed out in this answer.
The configuration via tracing plugin didn't really work out in my case, since no log output was created. Might have been some problem on my end.
The resulting trace output in the console was enough to indicate a problem where the Gradle output directory for .class files did not match up with what Eclipse expected to be the output directory, so it probably treated the folder as just another bunch of resources.
It also showed that the resolved classpath of each project was marked as changed on each project right after opening Eclipse. Not sure yet if the first issue is the cause of the second.