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