[
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-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
