Hello Jean! On 08/06/2021 17:21, Jean Helou wrote: > Hi benoit ! > > On my crusade to reorganize James code related to Guice apps (and >> promote their adoption), I come to the next item of the tick list (after >> ZIP packaging, JIB packaging to enable distribution). >> > These were great improvements > > >> I would like to make those application easier to find in the source tree. >> > and this one promises to be too ! > > >> Here would be the principles I would like to enforce: >> - All server applications should be collocated under the same directory >> - Server application modules should be clearly separated from guice >> module declarations >> >> I do not intend to fully reorder James directories just now but rather >> take small steps in a globally consensual direction. As such I propose >> the following directory layout as a first step: >> > This first step would be nice and at least would make it easy to add a link > to all the provided james-server builds in the readme, The instructions for > running each provided build could then go in the readme of each build and > reduce the clutter in the primary readme, I'm all for it :D > > But if you have a `first step` then you must also have a goal, it would be > easier to assess the usefulness of the first step if we shared the vision > of the goal. The goal would be that the directory structure : - reflects the project goals
- is honest toward the progress toward these goal - allow easily understanding the project architecture - and allow to easily find the project deliveries, tests, etc... - [add your goals here] I am starting with this last one, likely the easiest and less controversial to start with. > > I am partly aware of the history of the project and that some of the top > level directories are projects which used to live in different repositories > and have been merged back. so james git is essentially a mono-repo and > that's fine > > According to the website (which seems to have lost part of its colorful > landing page by the way) the primary components are : > - Server +1 > - Mailets +1, intended to be a generic API just like servlets are. Their use was intended outside of James. (source Dany Angus at ACEU 2019) This goal and its results could be re-assessed but I am not wishing to do this. > - Mailbox Regarding that one I do think mailbox do not make sense without a server to use it. I would be in favor to move it in the /server directory. A topic for another day. This module is tightly coupled with the protocols consuming it, underwent heavy changes during the JMAP implementations, and overall is a critical server component we need full control upon (eg performance). > - Protocols I do think protocols without a hard dependency on mailbox or server could be considered top level, but protocols like IMAP with a hard dependency on mailbox likely can't. > - MPT MPT is a weird thing. It mixes a set of tools along side with a test suite exercising other components. I think mpt/impl would deserve to be relocated. Maybe to /server/protocols/imap-tests /server/protocols/smtp-tests & /server/protocols/managesive-tests ? > > So I would expect these to be the top level directories in the project, > along with a couple supporting directories such as > - docs > - shared-libraries > maybe > - examples > > I included shared-libraries because I assume a reason for some of the > directories being top level is that they are used by multiple top level > modules : > my *guess* would be > - json > - core > - metrics > - testing/base > > Others sound like they should be reintegrated in the server directory tree > (guesstimate again) : > - backends-common Project with this dependency would also need to be in the server directory tree. This match the move of mailbox into server. > - event-bus > - event-sourcing > - benchmarks > - dockerfiles With the exception that it now mostly contains project related docker (compilation environment, websites) thus it can stands at "top level" in my opinion. > - grafana-reporting - third-party > > I have not taken the time to do a proper dependency analysis, this is just > how I expect to find the dependencies so I may be wrong :D We pretty much agree. > > If this organization is close to what you have in mind then the first step > is indeed the best. > > However If the goal is to push server in the spotlight then we should move > the apps directory to the top level and move mpt, mailets, mailbox, > protocols and mpt etc inside server > > Note that this doesn't prevent documenting them, nor publishing the > artifacts nor enforcing proper dependencies > > jean Benoit --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
