On 09/04/2012, at 8:11 PM, Luke Daley wrote: > On 09/04/2012, at 10:57 AM, Adam Murdoch <[email protected]> wrote: > >> 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. > > I think I'd prefer for these non domain classes to be separate, and for that > to be the characteristic for the module (non domain "utilities").
That reminds me: There is another group of classes that are domain specific, but which need to be reused in a bunch of places. These are things like GradleVersion, DistributionLocator, BuildLayoutFactory, the meta-data piece of WrapperExecutor. Things that provide meta-data about Gradle releases, and meta-data about the build environment of a given build. They are reusable (in core, launcher, the tooling api consumer, the wrapper task, the test fixtures), but definitely not 'low level utilities' or 'base services' or whatever. Perhaps a 'build environment' project. > > I don't think we need to try and contain the "core API" to one module. That > is, I don't see a problem with the "core API" being an aggregation o the > public API of several modules. > >> 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). > > Can we rename that as part of this? Yes we can. > >> 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. > > Right, I misunderstood above. You are taking about what I'd like to see > happen. > > If there's still a chance we'll merge from master to release before 1.0 then > I'd say we should wait until after cutting 1.0 to do this. Too much has changed in master for a merge now, I think. We should stick with fixing things on the release branch. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
