On Aug 29, 2009, at 8:30 AM, Adam Murdoch wrote:
Hans Dockter wrote:
I'd like to improve the package organization of the Gradle source
code.
The original idea was to have an org.gradle.api root package under
which all the interfaces lies that are supposed to be used by
Gradle users. org.gradle.api.internal contain the implementations
and helper classes. The infrastructure code for running a Gradle
build lies under the org.gradle root package.
I think this does not make sense any longer. From an embedded
perspective the infrastructure is as much api as the stuff under
org.gradle.api. And you also want to hook into the lifecycle from
your build script. Therefore I think it makes sense to get rid of
the api package all together.
I agree.
We would end up with org.gradle and org.gradle.internal as root
packages.
Then we'd end up with:
org.gradle.a
org.gradle.internal.a
org.gradle.a.b
org.gradle.internal.a.b
One problem with this is that related classes (a.b.c.d.* and
internal.a.b.c.d.*) are quite a bit apart in the hierarchy,
particularly as we get deeper in the package hierarchy.
Which can be good or bad depending on what you are interested in. If
you are only interested in the API this makes life easier.
It might be better to flip this round:
org.gradle.a
org.gradle.a.internal
org.gradle.a.b
org.gradle.a.b.internal
I don't feel strong about this. I had a look at the Eclipse code a
while ago. They use internal as 'root'.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
