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 > 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 > 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 > 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 - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
