You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "btellier@apache.org" <bt...@apache.org> on 2021/06/07 11:21:49 UTC
Code organisation: makes guice application easier to discover
Hello people,
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).
I would like to make those application easier to find in the source tree.
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:
```
server/apps/spring
-> today server/app
server/apps/memory
-> today server/container/guice/memory-guice
server/apps/cassandra
-> today server/container/guice/cassandra-guice
server/apps/cassandra-ldap
-> tests only
server/apps/distributed
-> today server/container/guice/cassandra-rabbitmq-guice
server/apps/cassandra-ldap
-> tests only
server/apps/jpa
-> today server/container/guice/jpa-guice
server/apps/jpa-smtp
-> today server/container/guice/jpa-smtp
server/container/guice/*
-> Location of guice modules, lifecycle, etc...
server/container/spring/*
-> Location of Spring stuff...
```
Would we reach a consensus of the usefulness of such a move before I
invest my time on it?
Regards,
Benoit
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Code organisation: makes guice application easier to discover
Posted by "btellier@apache.org" <bt...@apache.org>.
Nice to see some enthusiasm on this topic!
I did put https://github.com/apache/james-project/pull/487 applying this
proposal. (That, was quite boring to do!)
If people do not mind I would like to merge this timely as the scene is
now well set up for some majestic git conflicts drama...
Cheers,
Benoit
On 10/06/2021 17:43, tungtv202@gmail.com wrote:
> Hello Benoit,
>
> This is also the thing I want to do when the first time enters James'
> repository. Too many subdirectories in the root.
> One concern should put "not primary things" in the separate parent
> directory. Ex: benchmark, dockerfile, docs, grafana-reporting,
> third-party, testing...
>
> /Regards,/
>
> //
>
> /Tung, Tran Van/
>
> On 07/06/2021 18:21, btellier@apache.org wrote:
>> Hello people,
>>
>> 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).
>>
>> I would like to make those application easier to find in the source
>> tree.
>>
>> 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:
>>
>> ```
>> server/apps/spring
>> -> today server/app
>> server/apps/memory
>> -> today server/container/guice/memory-guice
>> server/apps/cassandra
>> -> today server/container/guice/cassandra-guice
>> server/apps/cassandra-ldap
>> -> tests only
>> server/apps/distributed
>> -> today server/container/guice/cassandra-rabbitmq-guice
>> server/apps/cassandra-ldap
>> -> tests only
>> server/apps/jpa
>> -> today server/container/guice/jpa-guice
>> server/apps/jpa-smtp
>> -> today server/container/guice/jpa-smtp
>> server/container/guice/*
>> -> Location of guice modules, lifecycle, etc...
>> server/container/spring/*
>> -> Location of Spring stuff...
>> ```
>>
>> Would we reach a consensus of the usefulness of such a move before I
>> invest my time on it?
>>
>> Regards,
>>
>> Benoit
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Code organisation: makes guice application easier to discover
Posted by "tungtv202@gmail.com" <tu...@gmail.com>.
Hello Benoit,
This is also the thing I want to do when the first time enters James'
repository. Too many subdirectories in the root.
One concern should put "not primary things" in the separate parent
directory. Ex: benchmark, dockerfile, docs, grafana-reporting,
third-party, testing...
/Regards,/
//
/Tung, Tran Van/
On 07/06/2021 18:21, btellier@apache.org wrote:
> Hello people,
>
> 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).
>
> I would like to make those application easier to find in the source tree.
>
> 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:
>
> ```
> server/apps/spring
> -> today server/app
> server/apps/memory
> -> today server/container/guice/memory-guice
> server/apps/cassandra
> -> today server/container/guice/cassandra-guice
> server/apps/cassandra-ldap
> -> tests only
> server/apps/distributed
> -> today server/container/guice/cassandra-rabbitmq-guice
> server/apps/cassandra-ldap
> -> tests only
> server/apps/jpa
> -> today server/container/guice/jpa-guice
> server/apps/jpa-smtp
> -> today server/container/guice/jpa-smtp
> server/container/guice/*
> -> Location of guice modules, lifecycle, etc...
> server/container/spring/*
> -> Location of Spring stuff...
> ```
>
> Would we reach a consensus of the usefulness of such a move before I
> invest my time on it?
>
> Regards,
>
> Benoit
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
Re: Code organisation: makes guice application easier to discover
Posted by Jean Helou <je...@gmail.com>.
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 btellier@apache.org <bt...@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-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
Re: Code organisation: makes guice application easier to discover
Posted by "btellier@apache.org" <bt...@apache.org>.
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-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Code organisation: makes guice application easier to discover
Posted by Jean Helou <je...@gmail.com>.
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