Open angelickite opened 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.
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.
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.
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.