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