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 Tue, 05 Aug 2008 11:48:25 GMT
Robert Burrell Donkin ha scritto:
> On Mon, Aug 4, 2008 at 12:59 AM, Stefano Bagnara <apache@bago.org> wrote:
>> user-api and user-library seems almost ok as modules, but I feel the
>> packages are wrong.
> 
> +1
> 
>> Is this something concerning also other developers or it's me too much
>> strict wrt packages/dependencies and this stuff?
> 
> no: illuminated issues with packages was one reason why i started the
> modularisation

Modules are really good at this. Thank you.
maven allow to easily create nice dependencies graph for modules, they 
are great to improve sources self-documentation.

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

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)

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.

>> e.g:
>>
>> 1) o.a.j.security is only used by user-library in the whole tree and
>> contains a single class. I'd like to move it to the generic "util-api"
>> module or to move it in the same package of DefaultUser (as it is the only
>> client for that class).
> 
> i have reservations about util-api but i'll detail these when i finish
> an earlier mail

I wrote a PROPOSAL for this. For the matter of this refactoring it could 
even be moved to the o.a.j.user package and left in this module.

>> 2) o.a.j.JamesMBean this is deprecated stuff, let's remove it, forever. We
>> have much more/better management interfaces now.
> 
> +1
> 
>> 3) the remaining packages should be refactored and moved to the
>> org.apache.james.user subpackage, introducing more nesting between api and
>> library and leaving space for functions to sub-package api/library packages.
> 
> sounds reasonable
> 
>> 4) after #3 I hope (and I'd like) to be able to support backward
>> compatibility by using a function module (or the phoenix-deployment module
>> as we'll need to "repackage" also functions later) having classes in the old
>> bad package.
> 
> i would like to see pheonix-deployed used to maintain compatibility

Yes, I see it is better than a function.
I hope it is possible, but we'll see if/when we'll actually try to do 
all of this.

Stefano

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


Mime
View raw message