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