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. 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 - Mailets - Mailbox - Protocols - MPT 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 - event-bus - event-sourcing - benchmarks - dockerfiles - grafana-reporting 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 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
