On 12/03/2013, at 5:14 AM, 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. The .api isn't supposed to be there. > >> (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 > > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com
