There's a company called Lattix (www.lattix.com) that makes a dependency discovery tool that may help to tease out what dependencies are in the code. They offer a free license to open source projects. Perhaps this tool would be of assistance. I've always wanted to give it a try myself, but if you guys find it useful, I'd love to see the results.
James On Tue, 2008-08-05 at 13:23 +0200, Stefano Bagnara wrote: > The issue raised in 3 different current threads, so maybe it is better > to talk about it in a new thread. > > While creating more modules there is the case where we use many utility > classes in our codebase. > > The current ant build is by purpose organized in 4 layers: > - deployments > - functions > - libraries > - apis > > Each layers module can only depends on modules in the underlying layers. > > What layer a module belongs to is automatically recognized by looking at > the module suffix. > > Currently our utilities are "hosted" in library modules, and this make > them useless to other library modules (utilities cannot be shared > between libraries). > > There is a long term plan of removing the utilities at all or to move > them to external libraries (hosted by JAMES or as part of already > existing Apache "Commons" libraries). My opinion is that similar plans > tend to move attention/efforts to the wrong goal. > > -------- > PROPOSAL > -------- > > I propose that we introduce a new kind (or two) of module at the same > level of the api module, so it would be: > - deployments > - functions > - libraries > - apis | commons | utils > > The new modules MUST have no dependencies on other modules as for APIs > but they are not API so having new types would help our refactoring in > the short term. > > I think this would also be useful to move some library code "down" to a > common/util module because this automatically make it clear that the > code have no dependencies on other servers libraries. > > I see the need for: > > deliverynotification code being discussed in "[server.trunk] introducing > mail-library" > > we then have some stream handling class, a security/digest class, maybe > some encoding/decoding class having no dependencies and being used by > unrelated code. My proposal is to put everything else in a single module > as a first step, and evaluate next steps once we see what ended up > inside the module. > > Maybe "deliverynotification-util" and "common-util" are good names for > the "-util" case, or "deliverynotification-common" and "util-common" are > an alternative in the "-common" case. > > ATM I would go with the -util suffix. > > > An alternative would be to use "-library" for the utilities (code with > no dependencies) and "-impl" for current libraries (they often are > implementations of stuff we have in -api modules). I don't have a strong > opinion on the best solution, I just have a strong feeling that we need > a fast/"easy to adopt" solution to accomplish a better modularization. > > Opinions? > > Stefano > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
