You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Stefano Bagnara <ap...@bago.org> on 2008/01/15 11:51:46 UTC
basic-user-function vs avalon-user-function
Hi Robert,
can you explain why you decided for an ad-hoc function module for
org.apache.james.vut.XMLVirtualUserTable
and
org.apache.james.userrepository.UsersLDAPRepository
instead of using the avalon-user-function for them, too?
In the svn log I see "Created module to home user implementations
without dependencies", but I don't understand what are the
"dependencies" that avalon-user-function has and that
basic-user-function doesn't want.
As far as I can tell the 2 classes above makes use of avalon stuff the
same way the org.apache.james.vut.JDBCVirtualUserTable or other classes
from avalon-user-function do...
I don't like too much to have a function for *2* almost *unrelated*
classes. At a first overview that's what I call antipattern of the
modularization, but it is possible that I'm missing the point behind
that choice.
Thank you,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: basic-user-function vs avalon-user-function
Posted by Bernd Fondermann <be...@googlemail.com>.
On Jan 16, 2008 7:46 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > 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.
>
> I agree. I was just explaining Bernd my opinion because he clearly
> misunderstood it.
ok, I gave a generalized justification for a specific complaint.
Although I might disagree in this specific case, I recognize your
concerns of too many modules. We have to think about every single
case, and that is what you did and I welcome this.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: basic-user-function vs avalon-user-function
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Jan 22, 2008 7:18 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > On Jan 16, 2008 9:10 PM, Stefano Bagnara <ap...@bago.org> wrote:
> >
> > <snip>
> >
> >> Mine was a really concrete, alternative, proposal: merge the 2 modules
> >
> > if you spelled it out like that before, then my apologies (i must have
> > missed it)
>
> Well, the subject of the thread and the first lines of my message:
> "can you explain why you decided for an ad-hoc function module for [2
> classes part of basic-user-function] instead of using the
> avalon-user-function for them, too?"
>
> I thought it was clear that the problem was the 2 modules (subject) and
> that the alternative was to have a single module (the end of the question).
i considered several reasonable possibilities before choosing the
2-module solution
i'm happy with the way the protocol modularlisation (SMTP and so on)
worked. i'm less happy with torque and the user stuff.
another alternative would be to adopt different strategies for
protocols and backends. perhaps it would be better to group all
implementations using a technology together. for example,
avalon-backend and (say) jcr-backend.
> I started asking why you did it, because I think I have to understand
> why you made a given choice before proposing something alternative.
it would have easier for me to understand and reply well if you'd
counterposed an alternative example
> BTW I will try to be more concrete in future criticism.
IMHO concrete positive suggestions are not criticisms :-)
<snip>
> >> I just think I should be entitled to tell anytime I like what are my
> >> preference and what is wrong IN MY OPINION. Once I do this others can
> >> take the time to agree or disagree with me, and we can understand what
> >> the community thinks about a given argument.
> >
> > i would find it easier to understand your arguments if they were
> > phrased as concepts rather than opinions. if you put forward clearly
> > your alternative ideas for JAMES then people could argue about these
> > ideas and some of them may well be adopted.
>
> I don't have a plan or alternative ideas on how to modularize the core
> library. Does this mean I'm not entitled to express my concern on what
> happens on the repository or to check whether the community share my
> concern or not? I hope not.
of course not but it would just be more effective if you used
alternative ideas as examples (even if they are just strawmen)
> I wrote multiple times, (too much times?), that you can go on with your
> plan, that I'm fine now that I expressed my concern and I know the
> community do not share my concern. I keep replying only because I feel
> you don't understand that I really accept community decisions and I'm
> not angry, stressed, or anything else WRT to trunk or the JAMES community.
i keep replying because i think i might learn something :-)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: basic-user-function vs avalon-user-function
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Jan 16, 2008 9:10 PM, Stefano Bagnara <ap...@bago.org> wrote:
>
> <snip>
>
>> Mine was a really concrete, alternative, proposal: merge the 2 modules
>
> if you spelled it out like that before, then my apologies (i must have
> missed it)
Well, the subject of the thread and the first lines of my message:
"can you explain why you decided for an ad-hoc function module for [2
classes part of basic-user-function] instead of using the
avalon-user-function for them, too?"
I thought it was clear that the problem was the 2 modules (subject) and
that the alternative was to have a single module (the end of the question).
I started asking why you did it, because I think I have to understand
why you made a given choice before proposing something alternative.
BTW I will try to be more concrete in future criticism.
> combining the basic and avalon means that the only user implementation
> components available would have a hard dependency on avalon even
> though there are user implementations which do not rely on avalon.
> this is incorrect from a dependency management perspective.
>
> there are other ways to approach this problem. if if is simply the
> number of modules that concerns you then one approach would be to
> divide the backend code into modules based on their dependencies.
I think it is not important what concern me as long as it does not
concern other developers of this community. I feel fine with any number
of modules as long as I see the benefits in term of new features and
increased community.
It was clear to me that modularizing the functions was much more easy
and that's why I tried to work on that as soon as you proposed the
modularization (this should prove I'm not against modularization
itself). I had it clear since your first proposal that modularization of
the core module would have been much more difficult and I don't have a
magic recipe for this.
I don't have enough english property to express my design/architectural
concerns, so I just tried to limit the discussion to the
avalon-user-function vs basic-user-function because I fear that
following the same pattern for the whole core will led us to create 100
modules and 100 modules, for JAMES Server, are too much. There are for
sure products where 100 modules are appropriate, but IMHO this is not
the case for JAMES Server and the current code complexity.
>> I just think I should be entitled to tell anytime I like what are my
>> preference and what is wrong IN MY OPINION. Once I do this others can
>> take the time to agree or disagree with me, and we can understand what
>> the community thinks about a given argument.
>
> i would find it easier to understand your arguments if they were
> phrased as concepts rather than opinions. if you put forward clearly
> your alternative ideas for JAMES then people could argue about these
> ideas and some of them may well be adopted.
I don't have a plan or alternative ideas on how to modularize the core
library. Does this mean I'm not entitled to express my concern on what
happens on the repository or to check whether the community share my
concern or not? I hope not.
I wrote multiple times, (too much times?), that you can go on with your
plan, that I'm fine now that I expressed my concern and I know the
community do not share my concern. I keep replying only because I feel
you don't understand that I really accept community decisions and I'm
not angry, stressed, or anything else WRT to trunk or the JAMES community.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: basic-user-function vs avalon-user-function
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Jan 16, 2008 9:10 PM, Stefano Bagnara <ap...@bago.org> wrote:
<snip>
> Mine was a really concrete, alternative, proposal: merge the 2 modules
if you spelled it out like that before, then my apologies (i must have
missed it)
combining the basic and avalon means that the only user implementation
components available would have a hard dependency on avalon even
though there are user implementations which do not rely on avalon.
this is incorrect from a dependency management perspective.
there are other ways to approach this problem. if if is simply the
number of modules that concerns you then one approach would be to
divide the backend code into modules based on their dependencies.
<snip>
> I just think I should be entitled to tell anytime I like what are my
> preference and what is wrong IN MY OPINION. Once I do this others can
> take the time to agree or disagree with me, and we can understand what
> the community thinks about a given argument.
i would find it easier to understand your arguments if they were
phrased as concepts rather than opinions. if you put forward clearly
your alternative ideas for JAMES then people could argue about these
ideas and some of them may well be adopted.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: basic-user-function vs avalon-user-function
Posted by Stefano Bagnara <ap...@bago.org>.
Robert,
there is no really need for such comments.
I clearly explained that I don't like that 2 specific modules. I made a
specific reference to the 2 modules and I think they should be a single
module. No one else share my personal preference, so we are done on this
issue.
Mine was a really concrete, alternative, proposal: merge the 2 modules ;-)
I'm not blocking anything. Instead I keep repeating that you should
continue with what you did. Please don't try to alter the meaning of my
messages.
I just think I should be entitled to tell anytime I like what are my
preference and what is wrong IN MY OPINION. Once I do this others can
take the time to agree or disagree with me, and we can understand what
the community thinks about a given argument.
I hope we can close this thread here,
Stefano
Robert Burrell Donkin ha scritto:
> On Jan 16, 2008 6:46 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>
> <snip>
>
>>> 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.
>> I don't know what you would consider "forward", starting from the
>> current trunk, so I will wait and I'll keep watching your efforts.
>
> by forward, i mean coming up with new solutions which you like and
> also satisfy our other requirements
>
> by backward, i mean blocking progress by negatively blocking changes
> you don't like with neither reasoned argument nor alternative proposal
>
>> My opinion is still that you can keep working that way. I change my
>> "old" +1 to a -0 just to let people know that things have gone
>> differently from what I understood,
>
> your vote's history now and it's too late for regrets: what matters is
> the codebase going forward
>
> the initial movements didn't really touch the backend of JAMES, just
> the protocols. i don't have the energy to argue with feeling or
> negotiate a consensus over the backend. i'm really not particularly
> wedded to any particular arrangement. if stuff feels wrong then please
> have a think and propose a better solution.
>
> - robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: basic-user-function vs avalon-user-function
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Jan 16, 2008 6:46 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
<snip>
> > 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.
>
> I don't know what you would consider "forward", starting from the
> current trunk, so I will wait and I'll keep watching your efforts.
by forward, i mean coming up with new solutions which you like and
also satisfy our other requirements
by backward, i mean blocking progress by negatively blocking changes
you don't like with neither reasoned argument nor alternative proposal
> My opinion is still that you can keep working that way. I change my
> "old" +1 to a -0 just to let people know that things have gone
> differently from what I understood,
your vote's history now and it's too late for regrets: what matters is
the codebase going forward
the initial movements didn't really touch the backend of JAMES, just
the protocols. i don't have the energy to argue with feeling or
negotiate a consensus over the backend. i'm really not particularly
wedded to any particular arrangement. if stuff feels wrong then please
have a think and propose a better solution.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: basic-user-function vs avalon-user-function
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> 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.
I agree. I was just explaining Bernd my opinion because he clearly
misunderstood it.
> 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.
I don't know what you would consider "forward", starting from the
current trunk, so I will wait and I'll keep watching your efforts.
My opinion is still that you can keep working that way. I change my
"old" +1 to a -0 just to let people know that things have gone
differently from what I understood, but maybe I'll see the real
advantages of that approach later.
Thank you,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: basic-user-function vs avalon-user-function
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Jan 16, 2008 9:41 AM, Stefano Bagnara <ap...@bago.org> 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 <ap...@bago.org> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: basic-user-function vs avalon-user-function
Posted by Stefano Bagnara <ap...@bago.org>.
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 <ap...@bago.org> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: basic-user-function vs avalon-user-function
Posted by Bernd Fondermann <bf...@brainlounge.de>.
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 <ap...@bago.org> 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.
>> 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.
>
> its the time to step in now ( maybe a bit late at all... ) ;-) Sorry if
> im so late. I don't like ( maybe its just of my missing understanding of
> ant ) the module stuff to much. For me its really not easy to see
> sometimes which module contain which stuff etc. I think its cool to make
> it easy to develop and replace modules, so the idea is not bad ( well
> its maybe really good). I think its probally "my problem", its just hard
> to understand all this stuff after i was so inactiv and not was able to
> follow all the changes the last months :-/
> Maybe there is a way to make it more "easy to use" ?
It needs some time to get used to it. This monolithic block of code is
just too cumbersome to move forward.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: basic-user-function vs avalon-user-function
Posted by Norman Maurer <no...@apache.org>.
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 <ap...@bago.org> 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).
>
> 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.
>
> Stefano
Hi,
its the time to step in now ( maybe a bit late at all... ) ;-) Sorry if
im so late. I don't like ( maybe its just of my missing understanding of
ant ) the module stuff to much. For me its really not easy to see
sometimes which module contain which stuff etc. I think its cool to make
it easy to develop and replace modules, so the idea is not bad ( well
its maybe really good). I think its probally "my problem", its just hard
to understand all this stuff after i was so inactiv and not was able to
follow all the changes the last months :-/
Maybe there is a way to make it more "easy to use" ?
Sorry for just step in now .....
bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: basic-user-function vs avalon-user-function
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Jan 15, 2008 1:51 PM, Stefano Bagnara <ap...@bago.org> 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).
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.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: basic-user-function vs avalon-user-function
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Jan 15, 2008 1:51 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > On Jan 15, 2008 10:51 AM, Stefano Bagnara <ap...@bago.org> wrote:
> >> Hi Robert,
> >>
> >> can you explain why you decided for an ad-hoc function module for
> >> org.apache.james.vut.XMLVirtualUserTable
> >> and
> >> org.apache.james.userrepository.UsersLDAPRepository
> >>
> >> instead of using the avalon-user-function for them, too?
> >
> > dependency management
> >
> >> In the svn log I see "Created module to home user implementations
> >> without dependencies", but I don't understand what are the
> >> "dependencies" that avalon-user-function has and that
> >> basic-user-function doesn't want.
> >>
> >> As far as I can tell the 2 classes above makes use of avalon stuff the
> >> same way the org.apache.james.vut.JDBCVirtualUserTable or other classes
> >> from avalon-user-function do...
> >
> > the classes contain avalon glue code but avalon is not essential to
> > their function
>
> The 2 reasons above IMHO do not justify the added work to mantain one
> more module.
i needed to have a home for a basic user meta-data repository
implementation. a module with 3 classes makes more sense than one with
one.
> 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.
however, i argue that the exercise as a whole is worthwhile: splitting
into a finely grained component system makes it easier to understand
what the dependencies really are. setting artificial limits on the
number of modules and the number of classes within a module will just
make everything more difficult.
poor COP is one of the major reasons why JAMES cannot attract more
developers. it's not possible just to do IMAP or SMTP or whatever
without dragging vast numbers of depenedencies in.
one of the major issues that i'd like to sort out is understanding
which API are internal and which external.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: basic-user-function vs avalon-user-function
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Jan 15, 2008 10:51 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> Hi Robert,
>>
>> can you explain why you decided for an ad-hoc function module for
>> org.apache.james.vut.XMLVirtualUserTable
>> and
>> org.apache.james.userrepository.UsersLDAPRepository
>>
>> instead of using the avalon-user-function for them, too?
>
> dependency management
>
>> In the svn log I see "Created module to home user implementations
>> without dependencies", but I don't understand what are the
>> "dependencies" that avalon-user-function has and that
>> basic-user-function doesn't want.
>>
>> As far as I can tell the 2 classes above makes use of avalon stuff the
>> same way the org.apache.james.vut.JDBCVirtualUserTable or other classes
>> from avalon-user-function do...
>
> the classes contain avalon glue code but avalon is not essential to
> their function
The 2 reasons above IMHO do not justify the added work to mantain one
more module.
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.
Thank you for the fast reply,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: basic-user-function vs avalon-user-function
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Jan 15, 2008 10:51 AM, Stefano Bagnara <ap...@bago.org> wrote:
> Hi Robert,
>
> can you explain why you decided for an ad-hoc function module for
> org.apache.james.vut.XMLVirtualUserTable
> and
> org.apache.james.userrepository.UsersLDAPRepository
>
> instead of using the avalon-user-function for them, too?
dependency management
> In the svn log I see "Created module to home user implementations
> without dependencies", but I don't understand what are the
> "dependencies" that avalon-user-function has and that
> basic-user-function doesn't want.
>
> As far as I can tell the 2 classes above makes use of avalon stuff the
> same way the org.apache.james.vut.JDBCVirtualUserTable or other classes
> from avalon-user-function do...
the classes contain avalon glue code but avalon is not essential to
their function
> I don't like too much to have a function for *2* almost *unrelated*
> classes. At a first overview that's what I call antipattern of the
> modularization, but it is possible that I'm missing the point behind
> that choice.
no: neither course or fine grained systems are pattern or
anti-patterns. overly fine granularity is a code smell.
the coursely-grained packaging system used in JAMES pretty much forces
a finely grained use of modules
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org