Hello everyone,

I intend to propose a PR which :
- groups guice queue bindings in server/container/guice/queue
- groups guice blob bindings in server/container/guice/blob

I have already done most of the work for the queues but realized I should
get feedback before spending more time on this before submitting this on
github.  The changes are visible in
https://github.com/jeantil/james-project/tree/extract-guice-modules

The branch currently has5 steps:
- move activemq bindings to guice/queue
- move rabbitmq bindings to guice/queue
- extract memory binding to guice/queue
- rename activemq binding module to queue-activemq-guice
- rename rabbitmq binding module to queue-rabbitmq-guice

Extracting `MemoryMailQueueModule` to its own module ( under
`server/container/guice/queue/memory` ) led to having to name that new
module. I ended up naming it `queue-memory-guice` and that in turn led to
the last 2 steps for consistency in this subtree.

Here is why I chose this naming scheme instead of the prevalent one in the
guice module:
- I felt the `james-server` prefix which is in most artifact names doesn't
bring much. There are a few other modules which dropped the prefix in
`server/container/guice` , and I prefer the lighter names. I am considering
also dropping the prefix from the 2 other queue modules in
`server/container/guice/queue` if I get positive feedback.
-  I found that  the server/container/guice/blob-xxx modules were easier to
identify/map to useful components than the other modules.
Looking at the `server/` subdirectories one can easily see different
components for the server which make perfect sense in the context of email,
the overall content is inferrable.
```
server
├── blob
├── data
├── dns-service
├── mailet
├── mailrepository
├── protocols
├── queue
├── task
```
I found that the blob-xxx-guice modules were very natural counterparts for
server/blob/blob-xxx and chose to follow that naming scheme for the memory
module.

Please let me know what you think

Also I feel this work matches
https://issues.apache.org/jira/browse/JAMES-1902 but maybe it needs its own
issue, please advise.

Best regards,
Jean

PS: I sent a first copy of this email before fully completing the
registration process to the dev list. I'm resending this now because I
don't see the message in the archive, please accept my apologies if this
results in a double send to the list.

Reply via email to