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