[jira] [Commented] (JAMES-3259) Reorganize source code

["Ioan Eugen Stan (Jira)" <se...@james.apache.org>]

    [ 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-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org