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. -- 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
