Splitties
Refactor tasks's name and descriptions
What?
Refactor tasks's names and descriptions
Why?
I wanted to experiment with extracting generating the kdocs of the build dependencies, but adding a dependency makes me realize we can do some house keeping. There were magic strings everywhere.
Now finding a given task is nice and tidy
How?
Define name/description in the Task (Companion) itself
Testing?
See the screenshot above and verify there are no mistakes
This also works quite well (looking for in-project usages of the register extension function for TaskContainer.
What I like about the current approach is that you can see right in the plugin class what the task names are, while if they are in the task class, you need to navigate for every single one, which opens a lot more files.
Why do you need to see the task names in a different way? Is the status quo an obstacle to something you're trying to achieve?
@LouisCAD
Why do you need to see the task names in a different way? Is the status quo an obstacle to something you're trying to achieve?
Yes that's a good question.
So your solution to look for tasks.register isn't bad either to be honest,
not perfect but it's an improvment compared to how I was doing it.
What I like about the current approach is that you can see right in the plugin class what the task names are, while if they are in the task class, you need to navigate for every single one, which opens a lot more files.
Not really because we have multiple plugins. If we had a single source of truth I wouldn't bother. Open the plugin class, done. But right now I frequently mix "oh no shit this one is in core, no in buildSrc, no in dependencies".
An alternative might be to open the name of the task class.
But that's not really how I mapp tasks in my mind.
For me the tasks are called refreshVersionsCleanup and buildSrcVersions
That they are implemented by RefreshVersionsCleanupTask and DefaultTask is an implementation detail.
Well actually you see, DefaultTask isn't a great name to remember right?