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