You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Plugins & extensions are great for setting up common defaults and simple scenarios, but ideally everything set by the gradle extension should map to a task property.
By introducing a common base class with shared configuration, and moving task-specific options to task properties you enable users to:
introduce their own custom tasks
have multiple instances of a task type
configure/override properties in the task rather than the plugin-extension
Like #13, this might be best approached as part of a major release as breaking changes may make sense.
The text was updated successfully, but these errors were encountered:
Worth considering and implementing, but I would prefer this to be an "it's there if you need it, but it's not required" feature.
Only reason for that being, we (or me, since I'm the sole dev on 95% of FDD projects) have a habit of making things as simple as possible, so that it's as noob friendly as possible.
This is something I've actually wanted to do since day one, but seeing how other plugins did it and how complicated it got, I decided against it (since the whole plugin was initially designed as an internal use plugin), but given how many users it gained recently, implementing things like this is worth the effort.
(Reminder to myself, set up a project for this, so these things can be tracked for a new update)
I agree we should strive for simplicity. Ideally, users would only need to configure their project IDs and secret keys and that'd be enough to have a sensible working configuration for 90% of cases.
One of the reasons I even thought about this, is that some niche features may be cluttering up the plugin extension when they may only be relevant to one specific task.
Even without a plugin extension, and configuring task properties directly, there's no reason for things to be more complex than they are now.
Would it be worth making a 3.0-dev branch that PRs can be submitted to? Even if it ends up being scrapped, it might be useful for experimenting.
Plugins & extensions are great for setting up common defaults and simple scenarios, but ideally everything set by the gradle extension should map to a task property.
By introducing a common base class with shared configuration, and moving task-specific options to task properties you enable users to:
Like #13, this might be best approached as part of a major release as breaking changes may make sense.
The text was updated successfully, but these errors were encountered: