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").
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?
> 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.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
