If no negative feedback, I will start implementing the nested structure
based on Stefano proposal this weekend.
Thx,
Eric
On 06/01/12 06:32, Eric Charles wrote:
Hi Stefano,
Yes, I remember the work you did analysing the modules in that jira.
I find the grouping in the jira not far away from the groups I defined.
The key points here are:
- Do we go to a 2 level structure ? (I would do it)
- Even if those groups are not usable as standalone alone component,
they can tend to. I don't care if a module depends on another module,
but they should be deployable without a full james sever. If we group,
we can smoothly tend to that.
Thx,
Eric
On 05/01/12 19:40, Stefano Bagnara wrote:
2012/1/5 Eric Charles<[email protected]>:
Hi there,
Doing recent protocols trunk integration in server, it became clear
to me
that our server components can be grouped together to form coherent
subcomponents (even usable outside James mail server, but that's another
story).
Please, read my comment to this issue from the last year (and maybe
the other comments to that issue too):
https://issues.apache.org/jira/browse/JAMES-1184?focusedCommentId=12983893&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12983893
As you can see my grouping proposal is opposite to your ;-)
I never pushed the grouping idea after that comment because I felt it
was not really necessary, "yet".
If you try to write dependency lines between the modules and the
"groups" you will understand why. Here is an old graph I used when I
made that proposal:
https://issues.apache.org/jira/secure/attachment/12468787/graph-server.gif
Using other words: the modules you are grouping are not really usable
"alone" as on the library/function level they have twisted
dependencies with other groups.
Stefano
btw, Recent Apache Hadoop mavenization gave birth to 38 modules (James
server modules can be considered small compared to these 38, even when
counting the mailbox and protocols modules).
So here's my first shot (it goes over grouping on name level, not
merging!!):
Curent list (prefixed with a 'Subcomponent Group')
1 container-spring
2 core (1 class module)
3 dnsservice-api
3 dnsservice-dnsjava
3 dnsservice-library
? fetchmail
4 filesystem-api
5 imapserver
5 lmtpserver
6 data-api
6 data-library
6 hbase
6 jpa
6 jcr
6 jdbc
6 file
4 lifecycle-api
1 lifecycle-spring
7 mailbox-adapter
8 mailetcontainer-api
8 mailetcontainer-camel
8 mailets
5 protocols-library
5 pop3server
5 smtpserver
9 queue-api
9 queue-file
9 queue-jms
9 queue-activemq
5 ldap
2 util
2 cli
Subcomponent Group Naming
1 container
2 util
3 dns
4 api
5 data
6 socket
7 adapter
8 mailet
9 queue
Let's talk about it.
(for the implementation, 2 options are possible : with or without
subparent)
Thx,
Eric
--
eric | http://about.echarles.net | @echarles
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
eric | http://about.echarles.net | @echarles
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
