Hi! First of all, why do you need to support Buildship 2.x versions? Do you need to support really old Gradle versions? Would it be possible to move those projects to newer Gradle versions (there are so many improvements in recent releases!).
Your findings are correct.
GradleCore.getWorkspace would be an expensive operation and not designed for your use-case.
The PersistentModel is internal but provides easy access to the build directory. You could use it for Buildship 2.x because we won’t do any releases for that major version.
You could use interface for Buildship 3.x as we won’t change it anytime soon. Still, we reserve the right to do it, so it’s not a guarantee. It might be better to use projectConfigurator extension point. If you reuse the init() method from BaseConfigurator then you will get the EclipseProject model from the cache, making the configurator execution cheaper.
Alternatively, you can combine the two solutions together and read the persistent model in a project configurator and exclude the build dir there. This way your custom code would be executed as part of the synchronization without dealing with loading the tasks. But again, it requires access to an internal API.
In any case, you’ll need two implementation, one for Buildship 2.x and one for 3.x. Unless you use reflection to load/read the PersistentModel depending on the current version (in Buildship 3.0 we moved it to a different package).