libgdx / gdx-liftoff

A modern setup tool for libGDX Gradle projects
Apache License 2.0
522 stars 48 forks source link

Grouping (libGDX) related gradle tasks together sensibly #187

Open angelickite opened 1 month ago

angelickite commented 1 month ago

As seen in https://github.com/libgdx/libgdx/issues/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 commented 1 month ago

A structure I could see work is something like

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 commented 1 month ago

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

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

tommyettinger commented 1 month ago

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.