[
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: [email protected]
For additional commands, e-mail: [email protected]
