james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: [server.trunk] user-api and user-library package names
Date Tue, 05 Aug 2008 19:31:23 GMT
On Tue, Aug 5, 2008 at 12:48 PM, Stefano Bagnara <apache@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>> On Mon, Aug 4, 2008 at 12:59 AM, Stefano Bagnara <apache@bago.org> wrote:


>>> we have these packages in user-api:
>>> o.a.j.vut
>>> o.a.j.api.user
>>> o.a.j.services
>>> then we have these in user-library:
>>> o.a.j.core
>>> o.a.j.management
>>> o.a.j.security
>>> o.a.j.services
>>> o.a.j.userrepository
>>> o.a.j.util
>>> o.a.j.vut
>>> o.a.j (for JamesMBean)
>> i think that this is too many
>> i would prefer all api's to be packaged under o.a.j.api.**.* so that
>> interfaces used internally from those intended to allow external
>> extension and so on
> What about
> moving this in the user-api module:
> - from user-api/o.a.j.services/Users*|James* to user-api/o.a.j.api.user
> - from user-api/o.a.j.services/Virtual* to user-api/o.a.j.api.vut
> - from user-api/o.a.j.vut to user-api/o.a.j.api.vut
> the vut and user packages do not need to be nested because they do not have
> dependencies (they could even be 2 separate modules, but this is a matter of
> style once the packages are correct and self contained).

sounds good to me

> move this classes from user-library to user-api in the
> o.a.j.api.vut.management package:
> o.a.j.management.VirtualUserTableManagementException
> o.a.j.vut.InvalidMappingException
> o.a.j.services.VirtualUserTableManagementService
> move this classes from user-library to user-api in the
> o.a.j.api.user.management package:
> o.a.j.management.UserManagementException
> o.a.j.management.UserManagementMBean
> (they simply expose "mutable" stuff for the User / VUTs)

i've been wondering about the coupling around remote manager and the
management interfaces for a while now. in some ways, i think that
management interfaces should be private so that implementations can
vary but i didn't find including them in higher layer worked for me
either. so let's try out this proposal.

> move o.a.j.services.JamesUser from library to user-api/o.a.j.api.user
> package.
> reorganize classe in user-library according to the repackaging of the api:
> they deserve a similar tree (user | vut | vut.management | user.management).
> This should make the library module much more compact in term of packages.

i dislike JamesUser and prefer smaller APIs but let's give this a go

- robert

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message