For me this is a +1.
I think there is several issue with today organization :
- Some projects are not really separated. For instance, if I want to
add QUOTA support, I will modify Mailbox interfaces, but also change
things in protocols.
- Having separated modules that are eavily changed makes build hard.
Today, you can either :
- build manually each projects in the correct order and install
the given jar in your .m2 repository. This is long, error prone, and not
documented.
- develop or rely on third party projects for aggregating this (
what we have done in james-parent ). This is not part of the Apache
project so relying on it seems strange to me. Moreover this tool is
designed for our needs ( our James with a Cassandra back-end ), with
tools we like ( docker ).
I think both of these options are not the good ones. We easily see
that modules like protocols, james, mailbox and mpt can't be built
separately.
- Work-flow is hard. Before starting working with Antoine and Matthieu
I was working on a PoC for IMAP quota, modifying mailbox and protocols
project on separated intelliJ instances. Each time I modified something
in mailbox, I needed to compile it, install it with maven and reload
maven in the protocol project, slowing me down a lot.
- Apache CI is broken. Quite normal as building James is not trivial.
- Library version can easily diverge between projects. It may be
unseen at compile time and with unit test but can cause serious problems
at runtime. Each time we modify a library version, we have to modify it
on each other James projects. This is error prone.
- Finally, there is the issue that started this thread. There might be
duplication between mailbox code and james-server-data-* one. In the
Cassandra example, we developed tools for creating tables, index, custom
types... That we want to use in both the cassandra-mailbox and
james-server-data-cassandra. We don't want to duplicate it, we don't
want dependencies between both projects. The only solution with
separated projects is to introduce an other separated project
introducing these tools ( what we started to develop ). This is not a
separated case : We can have uses of messages queue in several places :
mailqueue, mailbox event system, ... .
Merging modules together (mailbox, james, protocols and mpt for me )
solves all these issue elegantly and makes it easier to contribute to James.
Le 01/09/2015 11:29, Stephen Brewin a écrit :
On 01/09/2015 08:18, Matthieu Baechler wrote:
Thank you for your answer Stephen. It looks like we agree one this
proposal.
Can I take your answer for a +1 ?
+1 for restructuring
We should discuss transitioning to GIT separately
--Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
