We are migrating Eclipse Gradle plugins from Spring STS to Buildship and it’s raised a concern with the way that Buildship modifies the classpath.
With our previous setup we had our several projects with their several Eclipse configuration files setup exactly as intended and under version control and STS simply brought in the gradle dependencies that the config files were expecting.
Now with Buildship (2.2) if I choose “Refresh Gradle Project” from the context menu it overwrites the classpath file, rewriting some dependencies like the JRE and blowing away others like my Tomcat library.
I understand that Gradle plugins like “eclipse” and “eclipse-wtp” exists to allow you to generate these config files as you like through Gradle but that is not a tool that we have required because as I mentioned we version our eclipse configs just the way we like them.
With Buildship is it required to now use these plugins? If so, why isn’t there an option to use Buildship in a minimal approach where it simply brings in dependencies and leaves existing configuration alone? I don’t relish the idea of spending a couple of days understanding the eclipse-wtp plugin configuration and writing code to mirror all the existing config files in our many projects just because Buildship won’t leave the classpath alone.
1 Like
I sadly don’t have a solution but exactly the same problem: Migrating from STS to Buildship, having eclipse-settings versioned the way we need them.
I already have invested several days not to say weeks to fix the issues I run into by adding runtime containers for the serverenvironment and even more complex stuff having to mess around with the xml in the hooks. But it is really cumbersome to “script” all the settings for eclipse I could achive with a view clicks otherwise.
I agree with @christiancorey that I’d like to have the dependencys managed - that is what makes sense to keep in sync. There are some other settings like the java compiler-level I agree is useful. But I don’t see any benefit in lot’s of the other settings which are just to configure eclipse and aren’t relevant to a standalone build e.g. on the CI-server.
Maybe we missed something how this can be achived? But so far I didn’t find a way for “Refresh Gradle Project” not overwriting all the other stuff. If so: please open my eyes 
edit: add my Expectation:
I would like to have a statement from a gradle-expert here clarifying if I missed something how to achieve this or -if this is not intended by gradle/buildship at all- an explanation for this design decission to understand what additional benefits this solution has.
I’m more a gradle beginner than an expert - maybe there is a simple solution I still didn’t find after days of searching…?
1 Like