james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [server.trunk] user-api and user-library package names
Date Wed, 06 Aug 2008 07:51:06 GMT
Robert Burrell Donkin ha scritto:
> 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:
> <snip>
>>>> 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.

I see your point, indeed. I didn't evaluate this so good, so I'll 
refresh this once/if I'll put my hands on this issue.
BTW my first goal here is to have good packages, then if put some code 
in api instead of library it should be really easy to move it later again.
I don't think/plan we'll be able to get it right on the first attempt, 
but we have to move some step forward.

>> 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

IIRC this User / JamesUser / DefaultUser / DefaultJamesUser is something 
I always felt as weird. The api is User but everywhere in server code we 
check instanceof JamesUser and cast to it. Maybe overengineered 
considering that the api currently serve only server codebase.

But this is a different issue, I'd like to keep 
repackage/remodularization separated from other aspects, in order to 
keep the goal narrow.


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

View raw message