Thank you benoit for clarifying the goals you are reaching for, it's very clear for me now I agree with the goal, the plan and the first step :D
regards, Jean On Wed, Jun 9, 2021 at 7:15 AM btell...@apache.org <btell...@apache.org> wrote: > 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 > >
