On Jan 16, 2008 9:41 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Bernd Fondermann ha scritto: > > Norman Maurer wrote: > >> Am Dienstag, den 15.01.2008, 19:41 +0100 schrieb Stefano Bagnara: > >>> Robert Burrell Donkin ha scritto: > >>>> On Jan 15, 2008 1:51 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > >>>>> Btw If I am alone with this idea, then no problem. I just wanted to > >>>>> share that IMHO this (that module with 2 classes) makes no sense. > >>>> i'm not sure that the number of classes should be relevant: a better > >>>> test is whether the module is a logical and cohesive unit. in this > >>>> case, i agreed that it is debatable. but it's a code smell rather than > >>>> an anti-pattern. i would like to indicate clearly that there's > >>>> something not quite right about JAMES 3.0 rather than hiding it. > >>> I don't care if we want to call it anti-pattern, code smell or > >>> differently. I don't like it and I think it is complicating things > >>> instead of making it simpler (that was the original goal). > > > > What's complicated are the inherent dependencies. Making them explicit > > is not complicating them, but easier to deal with. > > I'm not talking about the whole modularization effort: if you remember > I've been the first to take the time to extract each function > (smtpserver, pop3server, fetchmail, spoolmanager, etc) to its own module. > > What I don't like is some of the module added in the last days. The best > example for what I don't like is the avalon-user-function + > basic-user-function.
the granularity of a module system is something that can be argued endlessly with no hope of consensus. IMO it would be a better use of energy to work out how we can effectively and efficiently modularize the JAMES backend. > And, I don't think it is making any dependency more explicit at this > time. If any, the dependencies, are made explicit by the pom.xml I'm > writing to keep the m2 build updated, because our ant build does not > make anything explicit. the ant build applies a small number of simple rules for dependency management and enforces some layering at compile time. it's only a stepping stone to a more comprehensive system but a useful one (i think) if you're concerned about maven maintenance, i'll generate the pom.xml > >>> But, again, if *I* am the only one with this vision then this > >>> conversation does not worth our time anymore :-) > >>> > >>> We probably just have different styles: you are the more active at > >>> the moment and no one else expressed his opinion. So your way is the > >>> right way. > > > > Well, I expressed at least once my great pleasure for the new layout > > since it allowed me to build an alternative deployment module which > > would otherwise have been much more difficult. > > Again, I'm not talking about THE modularization as a whole, I'm talking > about 2 specific modules, and THAT way to modularize. > When we planned modularisation we made a list of module candidates: > http://wiki.apache.org/james/Development/Modularisation > As you can see in trunk there are MUCH MORE modules than what we planned > at that time. > I just wanted to share that I'm +1 for modularization the way we planned > it and not the way it is starting to be in trunk. IMO prior approval has been killing JAMES. i outlined an approach but it's the general strategy which is important. modularisation was never intended to make things simpler but to make it easier for developers to collaborate and experiment, and to illuminate the complexity of the dependencies within the JAMES codebase. the current system is unsatisfactory but only a stepping stone. breaking down user related functions has been useful and interesting. if there are developers with sufficient energy out there to push forward modularisation in a different way with more forward planning, that's fine by me. i don't have enough energy to adopt that right now but don't let that stop you. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
