+1 On Mon, Mar 11, 2013 at 7:14 PM, Luke Daley <[email protected]>wrote:
> > On 11/03/2013, at 4:50 PM, Peter Niederwieser <[email protected]> wrote: > > > Hi all, > > > > it recently came up in one of my code reviews that plugin classes should > > live under `org.gradle.api.$function.plugins`, task classes under > > `org.gradle.api.$function.tasks`, and all other classes under > > `org.gradle.api.$function`. I'd like to question the use of the `plugins` > > and `tasks` subpackages. In my mind, the function should be dominant, and > > the `plugins` and `tasks` subpackages are often just unnecessary baggage > > (may contain just a single class, require extra imports, etc.). They also > > encourage to group only/primarily by plugins and tasks, rather than by > > function, which I think is the wrong axis of separation. (For an example, > > see the `plugins` subproject.) Hence, I propose that only > > `org.gradle.api.$function` should be mandatory, with the further package > > structure (if any) left to the plugin author. > > I'm with you on this. I don't think the .plugins or .tasks separation is > helpful. I'd prefer not to have it. > > I don't quite understand the .api namespace either, but I don't want to > derail this conversation with that. > > > (We'd probably still have to > > use `internal` for non-public packages.) > > > > We already have a couple of plugin subprojects that don't have `plugins` > and > > `tasks` subpackages, but I was asked to bring this up here for > > clarification. > > -- > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com > > Join me at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: > http://www.gradlesummit.com > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- Szczepan Faber Principal engineer@gradleware; Lead@mockito Join me at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com
