Buildship Eclipse: Custom tasks in the 'Gradle Tasks' view


(Phanindra) #1

I’m just getting started with Gradle. I imported a sample project into Eclipse. I added a dummy task in build.gradle.

task hello {...}

It showed up in the output of ‘gradle tasks’. However, that task didn’t show up in the ‘Gradle Tasks’ view. It’d be productive to have that feature. Not sure if I’m missing something.

Custom tasks show up in IntelliJ ‘Gradle Tasks’ window though.

(Phanindra) #2

I updated Eclipse and Buildship plugin. That involved a restart too. The task ‘hello’ started showing up in the Gradle Tasks’ view in Eclipse. Not sure if it’s due to the updates or the restart. Anyways, it’s working now.

(Donát Csikós) #3

There is a ‘refresh’ icon on the task view’s toolbar, if you modify the task list you can use that to make your changes visible.

(Guy) #4

I also find that the task I have defined in build.gradle doesn’t appear in the “Gradle Tasks View” in Eclipse. Refreshing (with the button described above) doesn’t cause it to appear, but it is listed under “other tasks” in the output of “gradle tasks”. The task itself runs fine if I run it from the gradle commandline though …

(Lance Java) #5

Tasks without a group are considered private and aren’t shown in buildship by default. This behaviour can be toggled so that private tasks are displayed

More info here

FWIW I think this default behaviour is a bit strange myself

(Stefan Oehme) #6

Yes, it has taken me by surprise too. On the other hand, it keeps the user from being confronted with a huge amount of low-level tasks, which is a good thing :slight_smile:

(Lance Java) #7

Agreed that a mechanism for hiding some tasks is a good idea. But a null groupId as the switch is an odd choice IMHO. I’d prefer an explicit public = false or private = true or similar

(Etienne Studer) #8

It is a general convention of the TAPI that public tasks are those that belong to a non-null group. Any changes on the concept of task visibility (both in the TAPI and on the cmd line) first need to be designed and decided on in Gradle core (and the TAPI would then be adjusted accordingly).

(Lance Java) #9

Yup, I realise that’s how it works currently. I am a big fan of the principal of least surprise. A public / private flag is far less surprising than a null group.

(Steve Cohen) #10

OK, I have some tasks that are defined in a custom plugin. They were not grouped so I didn’t see them. I added a group in the constructor of the base class of all my tasks setGroup('build'). This did not make the task show up under build. The only way I could see it was by turning on “show all tasks” which brought it under ‘other’, not under ‘build’. Restarting Eclipse did not help this. Neither did “Refresh Gradle Project” nor the refresh button on the Gradle Tasks view, just as if I had not called setGroup.

Evidently my way of giving the task a group was not the right way. How may I give a group to a task that is defined in a plugin so that this would work?

(Björn Kautler) #11

It seems you also need to set a description for it to land in the right category via TAPI.

(Stefan Oehme) #12

You don’t need a description. If you can reproduce that it would be a bug, please file an issue if that’s the case.