I figured out that BuildShip only imports projects and while that works up to a point, how will users be able to customize the project files built? As an example, I need to change the project output directory, add additional natures to the .project file and additional containers to the .classpath file. Will BS be updated to read the eclipse closure in the build.gradle or are there other mechanisms on the horizon?
We are aware of the need for customization and will tackle this. We have a rough plan for some of the customizations and will share it once the plan is a bit more fleshed out.
I sincerely hope that the approach will be to read the EclipsePluginConvention. It is a lightweight way of telling Gradle what it needs to know about my plugin. Many plugins out there are using it already. It would be a shame to duplicate that information somewhere else. Of course, for that to work, the EclipsePluginConvention needs an overhaul. It needs an abstraction for .settings files, source attachments etc. Currently these can only be changed by file manipulation, which is opaque to the tooling API.
Most importantly, please don’t make me write Eclipse Plugins just configure Buildship. I guess by now you have noticed how much of a hassle that is m2e went down that road and it was/is a disaster.
I’m not familiar with the concept of EclipsePluginConvention. We will look into it once we tackle project customization. In general, we want to keep as much of the configuration in the Gradle build files as possible.
It would help if you could describe a concrete use case of what you want to customize and how you envision to customize it.
Sorry, I confused the name, I meant the EclipseModel. Everything should be read from there. So we are completely on the same page when you say you want to keep things in the build file =)
But currently the EclipseModel is very limited. I does not know about source attachments, nor is there a general abstraction for .settings-files (it’s only there for jdt.core)
Yep. The information on the EclipseModel needs to make it through the Tooling API so we can leverage it there as well when setting of the Eclipse projects. And the EclipseModel itself most likely needs to be extended, as you already said.