> > 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. >
Sounds good. > 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). > Speaking about the tooling api. At some point it would be good to bust the tooling module, too. For example, it's not clear what classes should be used by the 'laucher' and what should remain an internal implementation. Also, I have a feeling at the moment it is easy to introduce subtle problem when someone uses a class he shouldn't and couple releases later he discovers that suddenly something cannot be refactored any more due to failing compatibility tests. > 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. > Do we want to keep the 'internal' package convention in the 'internal' modules? It feels a bit awkward in a way. However, I like the idea that the 'internal' sticks out when someone imports a class into his build.gradle. > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > -- Szczepan Faber Principal engineer@gradleware Lead@mockito
