On Wed, Aug 6, 2008 at 8:51 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > 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.
+1 definitely: i'm positive about the repackaging but we may need some more refinements later >>> 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. +1 - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
