I’m in the process of migrating a project from Gradle 3.5 to the latest. Developers are used to the Gradle Gui (which disappeared with Gradle 4 I think), so I’m looking into Buildship as a much better alternative.
However, I miss three essential features:
setting the project’s text file encoding to UTF8 (which is not the default encoding in Eclipse where I live)
setting the Java Editor’s Save Actions (this ensures everyone uses the same code style and minimizes formatting changes across developers)
SonarLint configuration
To this effect, I have two Gradle tasks that are triggered when ‘gradle eclipse’ is called, by making the eclipseProject task depend on my tasks.
However, when Buildship imports/refreshes a project, the ‘eclipseProject’ task is not called.
Is there a way to trigger custom tasks when importing projects? Or better yet, is there a way to declare this via Gradle (there wasn’t in 3.5, and there doesn’t seem to be in the latest either)?
For reference, here’s one of the tasks:
Is there a way to trigger custom tasks when importing projects?
Firstly, I don’t know about that, (nor about making tasks depend on eclipseProject in Buildship).
If you don’t find a cleaner solution via the Gradle DSLs, the main backdoor to advanced twiddling seems to be the eclipse { } block.
Unfortunately there’s an issue whereby code inside eclipse { project { beforeMerged & whenMerged} } are not invoked by Buildship’s “Refresh Gradle Project” action, which makes it inconsistent with generating .project files via invoking gradle eclipse on the command-line. (I’m looking at jumping in and fixing this in my spare time.)
But this let me think of one possible workaround: there are similar “hooks” defined in eclipse { classpath { } } which do get called by Buildship. There’s also eclipse { jdt }- but I’ve never tried that. It might be possible to add some “arbitrary code” in these to generate your .settings after which Eclipse will hopefully read it at the same time it reads the refreshed .project file.
(For the UTF8 part specifically, you may want to vote for
Thanks Luke, I went with using eclipse { project {whenMerged}, this works reasonably well (saw that you started working on issue 694, hope that’ll work out!).
Didn’t want to go this route at first because using tasks is cleaner & more effective (only run if inputs have changed), but realized my old tasks didn’t have any inputs/outputs, so I’m not losing anything here.
Having the option to call custom tasks would be better, still. If anyone from Buildship is listening, I’m curious to have an opinion on this.
We are aware that executing tasks upon synchronization is a highly requested feature. The plan is to implement it after the 3.0 release. The project is currently a bit understaffed, so I can’t make any promises about a deadline, but it should happen.