In my opinion this decision belongs to active developers: they are the users of the source tree and the build tools, so they are entitled to make the changes to feel confortable.
So, if active developers prefer to have a single branch, then you have my +1 for this. IIRC Robert was the main supporter of the split, so maybe he has something to say... And maybe they could be merged until we get to a more stable solution, and then splitted again once they are stable enough. The important thing is that a clear dependency is kept between modules and you don't introduce cyclic dependencies. Stefano PS: I'm happy to read there is something new on the james 3 codebase! On 1 September 2015 at 14:29, Benoit Tellier <be...@minet.net> 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
