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 (Issue Comment Edited) (JIRA)" <se...@james.apache.org> on 2012/01/10 11:02:38 UTC
[jira] [Issue Comment Edited] (JAMES-1362) Nest server modules
[ https://issues.apache.org/jira/browse/JAMES-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183172#comment-13183172 ]
Stefano Bagnara edited comment on JAMES-1362 at 1/10/12 10:00 AM:
------------------------------------------------------------------
Call me "limited"/"rigid" but I am against any grouping with circular/twisted dependencies.
Even ignoring the dependency issue I don't find it "useful", e.g:
- I can't imagine anyone using only the dns group outside james
- mailetcontainer and mailets have nothing to do each other. mailets contains very james specific classes, instead mailetcontainer is a more generic library.
- If we identify functional some group that "makes sense" then we should try to remove dependencies from other groups and move them to separate products (like protocols, mailbox, jspf, etc). So after you extract the "generic library" a group like "queue" would only contain 3-4 adapter classes. So the grouping doesn't correctly react to refactoring.
- Now that we extracted imap/protocols/mailets, james-server (escluding tests) is 2.4MB of java sources, less than 400 files. IMO it is not "so big" to require more organization (so I would embrace grouping only if I see a lot of value in it). You referenced Hadoop in another thread: hadoop has 4 base java modules and each one big as the whole james-server (core, mapred, hdfs, contrib modules are between 2 and 3MB java sources each one).
- I think our api modules are not "well-thought" (I'm guilt for this, too) but instead they are the results of fast dependency analysis and code refactorings (e.g: filesystem api is 1 class, lifecycle 4 class, dns-api 3 classes, queue-api 5 classes, mailetcontainer-api 7 classes). So I expect api modules to change, to see some merge between them and maybe some completely different aggregation on the api layer. This grouping would make a similar refactoring an harder task. At the current state I would prefer to have a single api module (we already have packages to separate concerns and most modules depends on more than half of that api modules).
- IMO James-server needs some more care/organization on the java architecture before we organize *current* java files even more than we already did.
That said I'm not active on the code, so I just wanted to give explanations on my thoughts and now I will better leave the decision to active committers (if I find some time I will try to create an updated dependency graph of the current modules as what I wrote is based on what we had in trunk 1 year ago and I may have missed some major changes).
was (Author: bago):
Call me "limited"/"rigid" but I am against any grouping with circular/twisted dependencies.
Even ignoring the dependency issue I don't find it "useful", e.g:
- I can't imagine anyone using only the dns group outside james
- mailetcontainer and mailets have nothing to do each other. mailets contains very james specific classes, instead mailetcontainer is a more generic library.
- If we identify functional some group that "makes sense" then we should try to remove dependencies from other groups and move them to separate products (like protocols, mailbox, jspf, etc). So after you extract the "generic library" a group like "queue" would only contain 3-4 adapter classes. So the grouping doesn't correctly react to refactoring.
- Now that we extracted imap/protocols/mailets, james-server (escluding tests) is 2.4MB of java sources, less than 400 files. IMO it is not "so big" to require more organization (so I would embrace grouping only if I see a lot of value in it). You referenced Hadoop in another thread: hadoop has 4 base java modules and each one big as the whole james-server (core, mapred, hdfs, contrib modules are between 2 and 3MB java sources each one).
- I think our api modules are not "well-thought" (I'm guilt for this, too) but instead they are the results of fast dependency analysis and code refactorings (e.g: filesystem api is 1 class, lifecycle 4 class, dns-api 3 classes, queue-api 5 classes, mailetcontainer-api 7 classes). So I expect api modules to change, to see some merge between them and maybe some completely different aggregation on the api layer. This grouping would make a similar refactoring an harder task. At the current state I would prefer to have a single api module (we already have packages to separate concerns and most modules depends on more than half of that api modules).
- IMO James-server needs some more care/organization on the java architecture before we organize *current* java files even more than we already did.
That said I'm not active on the code, so I just wanted to give explanations on my thoughts and now I will better leave the decision to active committers (if I find some time I will try to create an updated dependency graph of the current modules as what I wrote is based on what we had in trunk 1 year ago and I may have missed some major changes).
For easier historical navigation I add a link to an older issue:
https://issues.apache.org/jira/browse/JAMES-1184?focusedCommentId=12983893&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12983893
> Nest server modules
> -------------------
>
> Key: JAMES-1362
> URL: https://issues.apache.org/jira/browse/JAMES-1362
> Project: JAMES Server
> Issue Type: Improvement
> Components: Build System
> Affects Versions: Trunk
> Reporter: Eric Charles
>
> Group server module by function based on proposal found on https://issues.apache.org/jira/browse/JAMES-1184?focusedCommentId=12983893&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12983893
> I will publish here the resulting nesting before committing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org