Grouping (libGDX) related gradle tasks together sensibly

[angelickite]

As seen in libgdx/libgdx#7418, there can be some light confusion on which Gradle tasks are actually relevant to run in the context of a libGDX project. Thinking back many years when I didn't understand big words like Gradle myself, I can vaguely remember similar confusion, especially from the perspective of an out-of-the-box expectation.

It might make sense to ensure some sort of structure for tasks on the implementation level (i.e. beyond the documentation), so that tooling like an IDE can integrate more easily and beginners can just get started, i.e. improve the onboarding experience.

From a quick sample over platforms/Lwjgl3.kt and platforms/Android.kt I couldn't see that the tasks defined in there have configured a group or definition.

[angelickite]

A structure I could see work is something like

• libgdx
• libgdx-html
• libgdx-desktop
• ...
  for the 'public' API, and then
• libgdx-internal
• libgdx-html-internal
• libgdx-desktop-internal
• ...
  for the 'private' API (if needed).

I am currently not really familiar with the whole task grouping details of Gradle and only argue from the point of view of the consumer.

[angelickite]

If groups turn out to only 1-2 items each, a better structure might be:

• libgdx
  • desktop:dist
  • html:dist
  • ...

i.e. only have one libGDX group with all relevant base tasks.

[tommyettinger]

So the task grouping now (which only applies in IDEs, and Android Studio makes the task list harder to see) mostly uses the defaults. run is under lwjgl3/application. jar is under lwjgl3/build (it should be what dist calls on LWJGL3). The HTML tasks have superDev under html/gwt if I remember correctly, but dist is under html/other. I don't know if there's a way to group tasks from different projects in one parent group. I'm not sure if we can move important tasks like run from out of application, since that's created by the application plugin. We could create a synonymous task with a different name and group, like how jar and dist work.

I barely know how much of Gradle works myself, so I haven't actually put a task into a group yet. I figure it shouldn't be too hard... I am reluctant to move existing tasks where people are used to them, so new aliases in groups may make more sense.