Hi Benoit
There appears to be consensus that our project layout should be
refactored along the lines suggested by Matthieu. You seem to be
suggesting that we go further, which I believe we should hold off on.
With Matthieu's refactored structure a mulit-module Maven build that
uses a BOM (a bill-of-materials POM) will solve the majority of
problems. Then we can look at how to solve the remaining edge cases.
Personally I use Eclipse while you use IntelliJ, both of which integrate
with Maven and support multi-module projects. In my day job we have much
more complex multi-module projects than is proposed for James and have
no problems developing using Eclipse/Maven and with CI using Jenkins.
There should be no need for manual builds and installation of .jars.
These are signs of a Maven anti-pattern fixable with the appropriate
Maven multi-module structure or a misunderstanding of the Maven
development process.
Certainly I am not in favour of merging modules at this stage. As
explained in an earlier post, this breaks an intent of the James
project, plus it has yet to be shown to be beneficial under Matthieu's
refactored structure.
Sometimes it is best to take baby steps. I believe this is the case here.
Cheers
--Steve
On 01/09/2015 13:29, Benoit Tellier wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
