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 (JIRA)" <se...@james.apache.org> on 2011/01/09 23:50:46 UTC
[jira] Created: (JAMES-1181) Modules dependencies review
Modules dependencies review
---------------------------
Key: JAMES-1181
URL: https://issues.apache.org/jira/browse/JAMES-1181
Project: JAMES Server
Issue Type: Task
Components: Build System
Affects Versions: 3.0-M2
Reporter: Stefano Bagnara
Priority: Minor
Just opening an issue because it's simpler to share the image. This can even be closed as won't fix or resolved.
I found some time to checkout and take some review the current trunk, starting from modules dependencies.
I have to say the code seems better organized than some months ago, but the layers increased. This is not necessarily bad, but I think it worth noticing this.
On past we simply had 3 layers (api, library, function) with clear dependency scheme: libraries depending only on api, api having no dependencies, functions depending on api or libraries.
Now I tried to create an updated scheme and things are a bit more complicated now.
E.g:
util depends on dnsservice-api
core depends on util
mailetcontainer-library depends on core
So in this case between library and api we have 2 more layers.
I didn't investigate on the real classes creating this dependencies issues, so I don't know how feasible is to fix this "layering" and if it worth or not.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Resolved: (JAMES-1181) Modules dependencies review
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefano Bagnara resolved JAMES-1181.
------------------------------------
Resolution: Fixed
Fix Version/s: 3.0-M3
Assignee: Stefano Bagnara
> Modules dependencies review
> ---------------------------
>
> Key: JAMES-1181
> URL: https://issues.apache.org/jira/browse/JAMES-1181
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
> Affects Versions: 3.0-M2
> Reporter: Stefano Bagnara
> Assignee: Stefano Bagnara
> Priority: Minor
> Fix For: 3.0-M3
>
> Attachments: graph-server-check.gif, graph-server-edited.gif
>
>
> Just opening an issue because it's simpler to share the image. This can even be closed as won't fix or resolved.
> I found some time to checkout and take some review the current trunk, starting from modules dependencies.
> I have to say the code seems better organized than some months ago, but the layers increased. This is not necessarily bad, but I think it worth noticing this.
> On past we simply had 3 layers (api, library, function) with clear dependency scheme: libraries depending only on api, api having no dependencies, functions depending on api or libraries.
> Now I tried to create an updated scheme and things are a bit more complicated now.
> E.g:
> util depends on dnsservice-api
> core depends on util
> mailetcontainer-library depends on core
> So in this case between library and api we have 2 more layers.
> I didn't investigate on the real classes creating this dependencies issues, so I don't know how feasible is to fix this "layering" and if it worth or not.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-1181) Modules dependencies review
Posted by "Eric Charles (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979526#action_12979526 ]
Eric Charles commented on JAMES-1181:
-------------------------------------
I like 1 cause "If it can grow, it will grow".
And overall, Tks again for your help.
> Modules dependencies review
> ---------------------------
>
> Key: JAMES-1181
> URL: https://issues.apache.org/jira/browse/JAMES-1181
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
> Affects Versions: 3.0-M2
> Reporter: Stefano Bagnara
> Priority: Minor
> Attachments: graph-server-check.gif
>
>
> Just opening an issue because it's simpler to share the image. This can even be closed as won't fix or resolved.
> I found some time to checkout and take some review the current trunk, starting from modules dependencies.
> I have to say the code seems better organized than some months ago, but the layers increased. This is not necessarily bad, but I think it worth noticing this.
> On past we simply had 3 layers (api, library, function) with clear dependency scheme: libraries depending only on api, api having no dependencies, functions depending on api or libraries.
> Now I tried to create an updated scheme and things are a bit more complicated now.
> E.g:
> util depends on dnsservice-api
> core depends on util
> mailetcontainer-library depends on core
> So in this case between library and api we have 2 more layers.
> I didn't investigate on the real classes creating this dependencies issues, so I don't know how feasible is to fix this "layering" and if it worth or not.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-1181) Modules dependencies review
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980037#action_12980037 ]
Stefano Bagnara commented on JAMES-1181:
----------------------------------------
In my opinion it worth keeping the dependency layers as few as possible and be "rigorous" about dependencies, of course others may disagree with this.
That said, core have api dependencies, so it is a library.
A library should not depend on another library (otherwise we have 2 libraries layers and I think we should avoid it).
We don't have alternative implementations: we should organize code we have, not code we could have.
This will help people understand what we have and how to put their hands in.
I can find plenty of classes in the green modules (functions) that we may reuse in future and that could become part of a library, but we don't need this now and following the simple reasoning "it could be used by another implementation" will bring us to a module-per-class pattern.
So, as long as we don't have another mailetcontainer implementation I don't care of this issue (again, this is just my opinion and I count for 1 ;-) ): I would even move mailetcontainer-library code to the mailetcontainer-camel package (as it is the only user I don't see advantages in keeping modules separated: too many modules is not good, too).
My rule to keep things in order is:
api: they does not include implementation details, they do not have dependencies (or at most they have very common dependencies like mailet-api, javamail, commons-logging).
library: they only depends on apis or external jars. They don't depend on other internal libraries. These libraries should be shared by functions (no need to have a library when it is used only by a function)
functions: everything else. It is harder to see a case of "direct" reuse of a function jar. Most times we'll only have code reuse. I would prefer to limit function to function dependencies (i prefer to merge them instead).
We already have a lot of modules, I think we should try to control their grow and the number. Whenever there is no good motivation to have a module we should not create it.
OK, now I explained my way of thinking, If I didn't convince you that it worth then I will move back the JamesMailetContext and recreate the library-library dependency between mailetcontainer-library and core.
> Modules dependencies review
> ---------------------------
>
> Key: JAMES-1181
> URL: https://issues.apache.org/jira/browse/JAMES-1181
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
> Affects Versions: 3.0-M2
> Reporter: Stefano Bagnara
> Priority: Minor
> Attachments: graph-server-check.gif, graph-server-edited.gif
>
>
> Just opening an issue because it's simpler to share the image. This can even be closed as won't fix or resolved.
> I found some time to checkout and take some review the current trunk, starting from modules dependencies.
> I have to say the code seems better organized than some months ago, but the layers increased. This is not necessarily bad, but I think it worth noticing this.
> On past we simply had 3 layers (api, library, function) with clear dependency scheme: libraries depending only on api, api having no dependencies, functions depending on api or libraries.
> Now I tried to create an updated scheme and things are a bit more complicated now.
> E.g:
> util depends on dnsservice-api
> core depends on util
> mailetcontainer-library depends on core
> So in this case between library and api we have 2 more layers.
> I didn't investigate on the real classes creating this dependencies issues, so I don't know how feasible is to fix this "layering" and if it worth or not.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-1181) Modules dependencies review
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979524#action_12979524 ]
Stefano Bagnara commented on JAMES-1181:
----------------------------------------
I create the graph using a very raw bytecode dependency analyzer I written some years ago (it doesn't even support java5 stuff) and then I render the graph using yEd.
I would contribute my stuff to the project but it is really unusable by anyone but me and I have no time to make it better.
I agree with your concerns about core becoming the catch-all module, but I don't see a better placement and I think it is better to have some bloat in core than having one more layer in the dependency tree. My main concern is not with the layer itself, but the fact that an "util" package depends on "api": api and utils by definitions should not have internal dependencies. Also "util" is not a better catch-all than "core", don't you think?
The netmatcher stuff is used by mailet and smtpserver. They only share core and queue-api as dependencies.
So the 4 solutions I see for this are:
1- create a dnsservice-library as a new home for netmatcher/inetnetwork
2- use core and delay the split to module to the future if the dns related functions will grow
3- use dnsservice-api as the new home for netmatcher/inetnetwork (they are not directly api stuff but they depends on dnsservice, so this is anyway a better place)
4- move the network matching methods to dnsservice interface and then have the netmatcher+inetnetwork code moved between dnsservice-api and dnsservice-dnsjava. mailet and smtpserver would then depend on dnsservice-api only and at runtime to the dnsservice-dnsjava component.
I like all of them more than keeping them in "util". 4 is more complex than 1..3, so I would probably go for one in 1..3 and simply remember that we have 4 as possible improvement.
PS: I don't want to force "refactorings" as I don't have your same knowledge of the current code, so if you still think that leaving code where it is now is better I'll accept it :-) Otherwise let me know if you like some of the proposed changes and I'll try to find the time to apply them while I take some more confidence with the updated trunk.
> Modules dependencies review
> ---------------------------
>
> Key: JAMES-1181
> URL: https://issues.apache.org/jira/browse/JAMES-1181
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
> Affects Versions: 3.0-M2
> Reporter: Stefano Bagnara
> Priority: Minor
> Attachments: graph-server-check.gif
>
>
> Just opening an issue because it's simpler to share the image. This can even be closed as won't fix or resolved.
> I found some time to checkout and take some review the current trunk, starting from modules dependencies.
> I have to say the code seems better organized than some months ago, but the layers increased. This is not necessarily bad, but I think it worth noticing this.
> On past we simply had 3 layers (api, library, function) with clear dependency scheme: libraries depending only on api, api having no dependencies, functions depending on api or libraries.
> Now I tried to create an updated scheme and things are a bit more complicated now.
> E.g:
> util depends on dnsservice-api
> core depends on util
> mailetcontainer-library depends on core
> So in this case between library and api we have 2 more layers.
> I didn't investigate on the real classes creating this dependencies issues, so I don't know how feasible is to fix this "layering" and if it worth or not.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-1181) Modules dependencies review
Posted by "Norman Maurer (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980039#action_12980039 ]
Norman Maurer commented on JAMES-1181:
--------------------------------------
Thanks for explaining.. I agree with you about library-library dependencies and as you said we can move the classes later if needed. So I'm +1 for close this issue.
> Modules dependencies review
> ---------------------------
>
> Key: JAMES-1181
> URL: https://issues.apache.org/jira/browse/JAMES-1181
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
> Affects Versions: 3.0-M2
> Reporter: Stefano Bagnara
> Priority: Minor
> Attachments: graph-server-check.gif, graph-server-edited.gif
>
>
> Just opening an issue because it's simpler to share the image. This can even be closed as won't fix or resolved.
> I found some time to checkout and take some review the current trunk, starting from modules dependencies.
> I have to say the code seems better organized than some months ago, but the layers increased. This is not necessarily bad, but I think it worth noticing this.
> On past we simply had 3 layers (api, library, function) with clear dependency scheme: libraries depending only on api, api having no dependencies, functions depending on api or libraries.
> Now I tried to create an updated scheme and things are a bit more complicated now.
> E.g:
> util depends on dnsservice-api
> core depends on util
> mailetcontainer-library depends on core
> So in this case between library and api we have 2 more layers.
> I didn't investigate on the real classes creating this dependencies issues, so I don't know how feasible is to fix this "layering" and if it worth or not.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (JAMES-1181) Modules dependencies review
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefano Bagnara updated JAMES-1181:
-----------------------------------
Attachment: graph-server-edited.gif
> Modules dependencies review
> ---------------------------
>
> Key: JAMES-1181
> URL: https://issues.apache.org/jira/browse/JAMES-1181
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
> Affects Versions: 3.0-M2
> Reporter: Stefano Bagnara
> Priority: Minor
> Attachments: graph-server-check.gif, graph-server-edited.gif
>
>
> Just opening an issue because it's simpler to share the image. This can even be closed as won't fix or resolved.
> I found some time to checkout and take some review the current trunk, starting from modules dependencies.
> I have to say the code seems better organized than some months ago, but the layers increased. This is not necessarily bad, but I think it worth noticing this.
> On past we simply had 3 layers (api, library, function) with clear dependency scheme: libraries depending only on api, api having no dependencies, functions depending on api or libraries.
> Now I tried to create an updated scheme and things are a bit more complicated now.
> E.g:
> util depends on dnsservice-api
> core depends on util
> mailetcontainer-library depends on core
> So in this case between library and api we have 2 more layers.
> I didn't investigate on the real classes creating this dependencies issues, so I don't know how feasible is to fix this "layering" and if it worth or not.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-1181) Modules dependencies review
Posted by "Eric Charles (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980076#action_12980076 ]
Eric Charles commented on JAMES-1181:
-------------------------------------
Yes, Better more discussions than not saying/exposing things/ideas.
> Modules dependencies review
> ---------------------------
>
> Key: JAMES-1181
> URL: https://issues.apache.org/jira/browse/JAMES-1181
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
> Affects Versions: 3.0-M2
> Reporter: Stefano Bagnara
> Assignee: Stefano Bagnara
> Priority: Minor
> Fix For: 3.0-M3
>
> Attachments: graph-server-check.gif, graph-server-edited.gif
>
>
> Just opening an issue because it's simpler to share the image. This can even be closed as won't fix or resolved.
> I found some time to checkout and take some review the current trunk, starting from modules dependencies.
> I have to say the code seems better organized than some months ago, but the layers increased. This is not necessarily bad, but I think it worth noticing this.
> On past we simply had 3 layers (api, library, function) with clear dependency scheme: libraries depending only on api, api having no dependencies, functions depending on api or libraries.
> Now I tried to create an updated scheme and things are a bit more complicated now.
> E.g:
> util depends on dnsservice-api
> core depends on util
> mailetcontainer-library depends on core
> So in this case between library and api we have 2 more layers.
> I didn't investigate on the real classes creating this dependencies issues, so I don't know how feasible is to fix this "layering" and if it worth or not.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-1181) Modules dependencies review
Posted by "Norman Maurer (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979658#action_12979658 ]
Norman Maurer commented on JAMES-1181:
--------------------------------------
After a quick review it looks better from the dependency tree. Anyway It seems kind of "odd" to have these classes which not depend on any Camel class in the mailetcontainer-camel module, but maybe its just me ;)
About the nio-netty rename... what about protocols-library ?
> Modules dependencies review
> ---------------------------
>
> Key: JAMES-1181
> URL: https://issues.apache.org/jira/browse/JAMES-1181
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
> Affects Versions: 3.0-M2
> Reporter: Stefano Bagnara
> Priority: Minor
> Attachments: graph-server-check.gif, graph-server-edited.gif
>
>
> Just opening an issue because it's simpler to share the image. This can even be closed as won't fix or resolved.
> I found some time to checkout and take some review the current trunk, starting from modules dependencies.
> I have to say the code seems better organized than some months ago, but the layers increased. This is not necessarily bad, but I think it worth noticing this.
> On past we simply had 3 layers (api, library, function) with clear dependency scheme: libraries depending only on api, api having no dependencies, functions depending on api or libraries.
> Now I tried to create an updated scheme and things are a bit more complicated now.
> E.g:
> util depends on dnsservice-api
> core depends on util
> mailetcontainer-library depends on core
> So in this case between library and api we have 2 more layers.
> I didn't investigate on the real classes creating this dependencies issues, so I don't know how feasible is to fix this "layering" and if it worth or not.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-1181) Modules dependencies review
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980052#action_12980052 ]
Stefano Bagnara commented on JAMES-1181:
----------------------------------------
No api to api dependencies, too.
"util" is special because it is not an api but works like api: does not have any api dependency and libraries can depend on it. (so it is like an api module, but with a different name because in fact it does not represent an api).
Of course the guidelines can be worked around in various ways by simply moving modules to their own projects, but I think this make sense. If we find we need more than 3 layers in james-server then we should either find a way to simplify it or move some modules subtree to a separate project (like we did with protocols, with imap, with the mailet-apis).
PS: sorry if I repeat this, but in past we had community issues because people thought I was pushing too much "my way"/"my style". I simply explain what I would do. I explain why and I fight when I think the alternatives are wrong, but we are a community and my main rule is power to people that do things (so Eric and Norman in this case! I will try to convince you, but I will be happy also when you disagree and also when we have code I don't like. It is better to have code I don't like than not having code at all, or not having a community)
PS2: and thanks to Robert too because I took this "layering" rule from him and after fighting the rule (the restrictions!!) for a while I embraced it.
> Modules dependencies review
> ---------------------------
>
> Key: JAMES-1181
> URL: https://issues.apache.org/jira/browse/JAMES-1181
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
> Affects Versions: 3.0-M2
> Reporter: Stefano Bagnara
> Priority: Minor
> Attachments: graph-server-check.gif, graph-server-edited.gif
>
>
> Just opening an issue because it's simpler to share the image. This can even be closed as won't fix or resolved.
> I found some time to checkout and take some review the current trunk, starting from modules dependencies.
> I have to say the code seems better organized than some months ago, but the layers increased. This is not necessarily bad, but I think it worth noticing this.
> On past we simply had 3 layers (api, library, function) with clear dependency scheme: libraries depending only on api, api having no dependencies, functions depending on api or libraries.
> Now I tried to create an updated scheme and things are a bit more complicated now.
> E.g:
> util depends on dnsservice-api
> core depends on util
> mailetcontainer-library depends on core
> So in this case between library and api we have 2 more layers.
> I didn't investigate on the real classes creating this dependencies issues, so I don't know how feasible is to fix this "layering" and if it worth or not.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-1181) Modules dependencies review
Posted by "Eric Charles (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980044#action_12980044 ]
Eric Charles commented on JAMES-1181:
-------------------------------------
It's true that we should mitigate our module explosion and try to find the correct median approach
I can understand the library/library dependency should be avoided (except for utilities). Is the same logic to be applied for api (an api should not depend on another api) ?
I will take your definitions and push them to the web site so we have a kind of dev-rule.
+1 to let jira closed and let JamesMailetContext in mailetcontainer-camel, nice layers are much worth than potential code impl.
> Modules dependencies review
> ---------------------------
>
> Key: JAMES-1181
> URL: https://issues.apache.org/jira/browse/JAMES-1181
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
> Affects Versions: 3.0-M2
> Reporter: Stefano Bagnara
> Priority: Minor
> Attachments: graph-server-check.gif, graph-server-edited.gif
>
>
> Just opening an issue because it's simpler to share the image. This can even be closed as won't fix or resolved.
> I found some time to checkout and take some review the current trunk, starting from modules dependencies.
> I have to say the code seems better organized than some months ago, but the layers increased. This is not necessarily bad, but I think it worth noticing this.
> On past we simply had 3 layers (api, library, function) with clear dependency scheme: libraries depending only on api, api having no dependencies, functions depending on api or libraries.
> Now I tried to create an updated scheme and things are a bit more complicated now.
> E.g:
> util depends on dnsservice-api
> core depends on util
> mailetcontainer-library depends on core
> So in this case between library and api we have 2 more layers.
> I didn't investigate on the real classes creating this dependencies issues, so I don't know how feasible is to fix this "layering" and if it worth or not.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-1181) Modules dependencies review
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979636#action_12979636 ]
Stefano Bagnara commented on JAMES-1181:
----------------------------------------
I did the dnsservice-library stuff. I had also to move JamesMailetContext from mailetcontainer-library to mailetcontainer-camel in order to fix the "library-library" dependency issue.
Now the dependency tree is more appealing.
About renaming nio-netty to nio-library I've had a look at the content and I see there is a lot of jmx stuff an just 2 nio classes: I'm not sure what's the best name for this library so I leave it as is. Maybe "service-library" would be better as it contains stuff used by tcp services, but "service-library" is a really generic name, too similar to dnsservice-library.. so I don't have a better name for it right now.
> Modules dependencies review
> ---------------------------
>
> Key: JAMES-1181
> URL: https://issues.apache.org/jira/browse/JAMES-1181
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
> Affects Versions: 3.0-M2
> Reporter: Stefano Bagnara
> Priority: Minor
> Attachments: graph-server-check.gif, graph-server-edited.gif
>
>
> Just opening an issue because it's simpler to share the image. This can even be closed as won't fix or resolved.
> I found some time to checkout and take some review the current trunk, starting from modules dependencies.
> I have to say the code seems better organized than some months ago, but the layers increased. This is not necessarily bad, but I think it worth noticing this.
> On past we simply had 3 layers (api, library, function) with clear dependency scheme: libraries depending only on api, api having no dependencies, functions depending on api or libraries.
> Now I tried to create an updated scheme and things are a bit more complicated now.
> E.g:
> util depends on dnsservice-api
> core depends on util
> mailetcontainer-library depends on core
> So in this case between library and api we have 2 more layers.
> I didn't investigate on the real classes creating this dependencies issues, so I don't know how feasible is to fix this "layering" and if it worth or not.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-1181) Modules dependencies review
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979428#action_12979428 ]
Stefano Bagnara commented on JAMES-1181:
----------------------------------------
Also:
1) nio-netty and repository-file seems to have a "library" role from the schema: what about postfixing them with library?
2) the util -> dnsservice-api dependencies seems to be caused by the util.netmatcher package (and the "private" util.inetnetwork package). It seems this stuff could be safely moved to the "core" module removing one full layer (and having all of the "api" modules + "util" in a single layer with no dependencies).
> Modules dependencies review
> ---------------------------
>
> Key: JAMES-1181
> URL: https://issues.apache.org/jira/browse/JAMES-1181
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
> Affects Versions: 3.0-M2
> Reporter: Stefano Bagnara
> Priority: Minor
> Attachments: graph-server-check.gif
>
>
> Just opening an issue because it's simpler to share the image. This can even be closed as won't fix or resolved.
> I found some time to checkout and take some review the current trunk, starting from modules dependencies.
> I have to say the code seems better organized than some months ago, but the layers increased. This is not necessarily bad, but I think it worth noticing this.
> On past we simply had 3 layers (api, library, function) with clear dependency scheme: libraries depending only on api, api having no dependencies, functions depending on api or libraries.
> Now I tried to create an updated scheme and things are a bit more complicated now.
> E.g:
> util depends on dnsservice-api
> core depends on util
> mailetcontainer-library depends on core
> So in this case between library and api we have 2 more layers.
> I didn't investigate on the real classes creating this dependencies issues, so I don't know how feasible is to fix this "layering" and if it worth or not.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (JAMES-1181) Modules dependencies review
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefano Bagnara updated JAMES-1181:
-----------------------------------
Attachment: graph-server-check.gif
> Modules dependencies review
> ---------------------------
>
> Key: JAMES-1181
> URL: https://issues.apache.org/jira/browse/JAMES-1181
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
> Affects Versions: 3.0-M2
> Reporter: Stefano Bagnara
> Priority: Minor
> Attachments: graph-server-check.gif
>
>
> Just opening an issue because it's simpler to share the image. This can even be closed as won't fix or resolved.
> I found some time to checkout and take some review the current trunk, starting from modules dependencies.
> I have to say the code seems better organized than some months ago, but the layers increased. This is not necessarily bad, but I think it worth noticing this.
> On past we simply had 3 layers (api, library, function) with clear dependency scheme: libraries depending only on api, api having no dependencies, functions depending on api or libraries.
> Now I tried to create an updated scheme and things are a bit more complicated now.
> E.g:
> util depends on dnsservice-api
> core depends on util
> mailetcontainer-library depends on core
> So in this case between library and api we have 2 more layers.
> I didn't investigate on the real classes creating this dependencies issues, so I don't know how feasible is to fix this "layering" and if it worth or not.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-1181) Modules dependencies review
Posted by "Norman Maurer (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979556#action_12979556 ]
Norman Maurer commented on JAMES-1181:
--------------------------------------
Thanks for your feedbacks (Stefano/Eric).
>From my point of view this would make sense:
1) nio-netty -> nio-library ?
2) create dnsservice-library and move the netmatcher stuff in there plus the MXHostAddressIterator
WDYT ?
> Modules dependencies review
> ---------------------------
>
> Key: JAMES-1181
> URL: https://issues.apache.org/jira/browse/JAMES-1181
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
> Affects Versions: 3.0-M2
> Reporter: Stefano Bagnara
> Priority: Minor
> Attachments: graph-server-check.gif
>
>
> Just opening an issue because it's simpler to share the image. This can even be closed as won't fix or resolved.
> I found some time to checkout and take some review the current trunk, starting from modules dependencies.
> I have to say the code seems better organized than some months ago, but the layers increased. This is not necessarily bad, but I think it worth noticing this.
> On past we simply had 3 layers (api, library, function) with clear dependency scheme: libraries depending only on api, api having no dependencies, functions depending on api or libraries.
> Now I tried to create an updated scheme and things are a bit more complicated now.
> E.g:
> util depends on dnsservice-api
> core depends on util
> mailetcontainer-library depends on core
> So in this case between library and api we have 2 more layers.
> I didn't investigate on the real classes creating this dependencies issues, so I don't know how feasible is to fix this "layering" and if it worth or not.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-1181) Modules dependencies review
Posted by "Eric Charles (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980024#action_12980024 ]
Eric Charles commented on JAMES-1181:
-------------------------------------
Couldn't the abstract JamesMailetContext be implemented by a mailetcontainer other that Camel?
If yes, it could be moved from mailet-container-camel to a module agnostic from camel (mailetcontainer-library, even if I read Stefano comment "Definitely move JamesMailetContext to the camel function as it also depends on MailImpl (core library).", not sure to see where why mailetcontainer-library can not depend on core, even if all I see in "core" is Mime* and Mail*, that sounds to me like "core" could be renamed to "mail" (or "mime").
> Modules dependencies review
> ---------------------------
>
> Key: JAMES-1181
> URL: https://issues.apache.org/jira/browse/JAMES-1181
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
> Affects Versions: 3.0-M2
> Reporter: Stefano Bagnara
> Priority: Minor
> Attachments: graph-server-check.gif, graph-server-edited.gif
>
>
> Just opening an issue because it's simpler to share the image. This can even be closed as won't fix or resolved.
> I found some time to checkout and take some review the current trunk, starting from modules dependencies.
> I have to say the code seems better organized than some months ago, but the layers increased. This is not necessarily bad, but I think it worth noticing this.
> On past we simply had 3 layers (api, library, function) with clear dependency scheme: libraries depending only on api, api having no dependencies, functions depending on api or libraries.
> Now I tried to create an updated scheme and things are a bit more complicated now.
> E.g:
> util depends on dnsservice-api
> core depends on util
> mailetcontainer-library depends on core
> So in this case between library and api we have 2 more layers.
> I didn't investigate on the real classes creating this dependencies issues, so I don't know how feasible is to fix this "layering" and if it worth or not.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-1181) Modules dependencies review
Posted by "Norman Maurer (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980072#action_12980072 ]
Norman Maurer commented on JAMES-1181:
--------------------------------------
and your comments are very welcome..
> Modules dependencies review
> ---------------------------
>
> Key: JAMES-1181
> URL: https://issues.apache.org/jira/browse/JAMES-1181
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
> Affects Versions: 3.0-M2
> Reporter: Stefano Bagnara
> Priority: Minor
> Attachments: graph-server-check.gif, graph-server-edited.gif
>
>
> Just opening an issue because it's simpler to share the image. This can even be closed as won't fix or resolved.
> I found some time to checkout and take some review the current trunk, starting from modules dependencies.
> I have to say the code seems better organized than some months ago, but the layers increased. This is not necessarily bad, but I think it worth noticing this.
> On past we simply had 3 layers (api, library, function) with clear dependency scheme: libraries depending only on api, api having no dependencies, functions depending on api or libraries.
> Now I tried to create an updated scheme and things are a bit more complicated now.
> E.g:
> util depends on dnsservice-api
> core depends on util
> mailetcontainer-library depends on core
> So in this case between library and api we have 2 more layers.
> I didn't investigate on the real classes creating this dependencies issues, so I don't know how feasible is to fix this "layering" and if it worth or not.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-1181) Modules dependencies review
Posted by "Eric Charles (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979510#action_12979510 ]
Eric Charles commented on JAMES-1181:
-------------------------------------
Hi Stefano,
For the record, there is a module dependency view (not updated, it's moving too fast for now) in https://svn.apache.org/repos/asf/james/server/trunk/src/site/resources/model-eclipse-modeler/
It's done with eclipse modeler and it's goal was to show the server module dependencies towards imap, mailbox, protocols.
Is your graph automatically generated ? Which tool did you use ? (maybe we could use the same have have it in svn so anyone can let it evolve) - yes, picture, especially with colors, tell more than words :)
About the util dnservice-api dep, we moved the netmatcher to util, cause it was not worth a module. However, I fear about moving netmatcher to core, cause it will make core the default place for all stuff not having a real place. but I don't have other proposal to give you..
> Modules dependencies review
> ---------------------------
>
> Key: JAMES-1181
> URL: https://issues.apache.org/jira/browse/JAMES-1181
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
> Affects Versions: 3.0-M2
> Reporter: Stefano Bagnara
> Priority: Minor
> Attachments: graph-server-check.gif
>
>
> Just opening an issue because it's simpler to share the image. This can even be closed as won't fix or resolved.
> I found some time to checkout and take some review the current trunk, starting from modules dependencies.
> I have to say the code seems better organized than some months ago, but the layers increased. This is not necessarily bad, but I think it worth noticing this.
> On past we simply had 3 layers (api, library, function) with clear dependency scheme: libraries depending only on api, api having no dependencies, functions depending on api or libraries.
> Now I tried to create an updated scheme and things are a bit more complicated now.
> E.g:
> util depends on dnsservice-api
> core depends on util
> mailetcontainer-library depends on core
> So in this case between library and api we have 2 more layers.
> I didn't investigate on the real classes creating this dependencies issues, so I don't know how feasible is to fix this "layering" and if it worth or not.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org