Robert Burrell Donkin ha scritto:
On Mon, Aug 4, 2008 at 12:59 AM, Stefano Bagnara <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
