Re: Server modules Naming/Grouping
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 Charlese...@apache.org: 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=12983893page=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: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org -- eric | http://about.echarles.net | @echarles - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Server modules Naming/Grouping
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). 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: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: Server modules Naming/Grouping
2012/1/5 Eric Charles e...@apache.org: 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=12983893page=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: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: Server modules Naming/Grouping
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 Charlese...@apache.org: 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=12983893page=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: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org -- eric | http://about.echarles.net | @echarles - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
