On 28/03/2013, at 9:13 AM, Luke Daley <[email protected]> wrote:
> > On 27/03/2013, at 4:59 PM, Adam Murdoch <[email protected]> wrote: > >> >> On 28/03/2013, at 1:33 AM, Peter Niederwieser <[email protected]> wrote: >> >>> Adam Murdoch wrote >>>> We could possibly implement this by traversing and inspecting the static >>>> dependency graph between types, so that, for example, a type that is >>>> reachable from a Task type cannot then depend on any Task or Plugin types. >>>> >>>> I think, however, naming scheme is the simplest option - this might mean >>>> prefixing or suffixing types with their role, or separating roles into >>>> packages, or some combination. >>> >>> If we truly need to know the roles at compile time, and not just for plugin >>> and task classes, >> >> Just to clarify: We don't necessarily need to know at compile time, but I do >> want the CI build to fail if any of these things are tangled. So, there's >> some kind of static inspection going on. >> >>> then a package naming scheme is the clear winner for me. >> >> The question then is what the scheme should be. >> >>> Question is how to make things work for all the existing code that doesn't >>> fit the agreed upon naming scheme. >> >> If we go with a package naming scheme, then for incubating classes, we'll >> move the classes to the new packages. For public classes, we'll can exclude >> them or make the inspections tweakable (as the existing classes are already >> separated to various degrees). >> >> If we go with some source/bytecode analysis, then the existing stuff should >> just work. > > What are the downsides of this approach? We need some way to figure out which group a given class lives in, so it depends a bit on how we decide to do this. Right now, we can figure out that a class is-a Task or is-a Plugin. We can continue to use package naming scheme to separate out the internal stuff. So, we might assume that anything that isn't a Task or a Plugin or isn't internal is a model class. It doesn't quite allow us to really separate out the model, but might be good enough. We could potentially mark up model types with an annotation or interface, so that we can separate them out from the 'everything else' bucket. There are other reasons why this might be useful, but I think they're off in the distant future. The main downside is that we have to implement this scheme, whereas the naming scheme checking already works. -- 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
