[ 
https://issues.apache.org/jira/browse/JAMES-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150440#comment-17150440
 ] 

Ioan Eugen Stan commented on JAMES-3259:
----------------------------------------

After working on the gradle migration and reading [~dleangen]'s email I belive 
the structure should be driven by the business needs / end products and not the 
technologies we use. 

- imap server
- smpt server
- jmap server
- pop3 server

For each server there are of course multiple implementations: jdbc/jpa , 
cassandra, etc. 
When the servers are composed and run in a single process, it makes sense to 
use implementations that use the same technology (e.g. all server 
implementations that use Cassandra) , to avoid operational overhead. 

I believe that is important for us to have boundaries around the server 
implementations so that:
* If I am only using SMPT in my application, I should be able to 
** develop and work on the SMTP implementation
** run the integration tests only for SMPT implementations
** run only the SMTP server in production
** I should not have to care about the IMAP implementation since there is no 
way I can break that.

Inside the SMTP project:
* There can be multiple implementation
* We should have a very good set of integration tests that focus on SMTP 
regardless of implementation 
* We can have a thin set of integration tests that focus on technology 
specifics - cassandra, jpa, etc

Right now I can't easily work just on SMTP or just on IMAP since the code is 
highly coupled.
I have to run ALL the integration tests, even if I care about SMTP and no the 
others. 
Also, for SMTP, if I care only about RabbitMQ implementation, it should be easy 
for me to focus just on that.
Once I am done developing, I should be able to run just the suite of SMTP 
integration tests for my changes. 

The above suggestions are just that, suggestions.
They are by no means perfect and please share your constructive ideas.
The goal is to focus less on a a perfect, complete "James Server" and more on: 
Hey we have a SMTP, IMAP, POP3 servers and you can build your own email server 
with them. 
We can and should provide a distribution with all of them in the same app, but 
that should be a side-effect and a bonus of how we organize.


> Reorganize source code
> ----------------------
>
>                 Key: JAMES-3259
>                 URL: https://issues.apache.org/jira/browse/JAMES-3259
>             Project: James Server
>          Issue Type: Improvement
>    Affects Versions: 3.5.0
>            Reporter: Matthieu Baechler
>            Priority: Major
>
> I want to suggest a new organization of the source-code (I won't handle every 
> concerns but some important ones I have about the current state).
> I would like the first level to be:
> {code}
> core (domain code)
> data (that we should rename)
> docs
> extensions (containing mdn and third-party for example)
> infrastructure (containing backends-common, event-sourcing, json, metrics)
> mailbox
> mailet
> products (containing server/container/cli 
> server/container/guice/cassandra-rabbitmq-guice)
> protocols
> server
> testing (containing mpt)
> {code}
> I'm not sure it's the best organization but:
> * it allows to see easily what james most important concepts are
> * put technical details into a common sub-tree
> * have products a top level thing instead of a hidden one
> * group what we think are extensions somewhere
> * put functional testing sources somewhere that is easy to find (because a 
> lot of people starts by reading functional tests)
> What do you think?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Reply via email to