Bertrand Delacretaz wrote: > On 10/26/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > >> Bertrand Delacretaz wrote: >>> ... I'd put all of this inside the "sling.api" package instead of >>> "sling".... > >> ...I think the "api" in the package name is superfluous :) It's clear that >> if the package is o.a.sling that this is the api.... > > If you see it in isolation, of course you're right. > > But if someone sees all the Sling code in the same tree (for example > with merged javadocs from all Sling modules) you'd have something like > that, not? > > core > exceptions (*) > helpers (*) > jcr > osgi > params (*) > > See what I mean? The (*) packages are from the API, the others are > from the implementations of the various modules. They're all mixed up > now. > I think "now" is key here :) We should move implementation stuff to a sub package like "impl.foo". In addition with OSGi, implementations are private stuff and hidden and not available through the classpath. Of course this is just at runtime. But we shouldn't provide javadocs for the implementation stuff.
Anyway, I think there are two solutions: a) use "api" as a sub package and imply that all api is in this package or a sub package of this. All other packages are private. b) use "impl" as sub package and imply that everything is public except stuff in "impl" sub packages. As one usually uses (should use) api stuff I prefer short package names and I would tend to b) :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
