Hi, I'm just looking at busting up the core project a bit. In particular, I'd like to bust out the messaging stuff, so that it is reusable outside the core. One question is what to do with the public API classes that it uses - things like Action, Transformer, Factory, GradleException, etc.
My plan is to move these domain-independent public classes to the baseServices project. This means that the 'core' API will be spread over 2 projects: baseServices and core. This feels a little awkward right now, but I think it is the direction to go, given that we want to further split up the core API and move the dependency management pieces to the coreImpl project (aka the dependencyManagement project). It also means that we can start to share some of these general-purpose things with the tooling API (e.g. @Nullable might be nice to reuse). So, the end result will be that each 'core' project will have a (potentially empty) public API, and a private implementation, which fits well with how the plugin projects are structured. I think this is a better structure than having a project that contains the whole core API, and a bunch of separate implementation projects that hang off it. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
