+1 On Mon, Aug 24, 2015 at 3:37 PM, Matthieu Baechler <mbaech...@linagora.com> wrote:
> Hi all, > > For some months, Antoine Duprat, Benoit Tellier and myself are working > daily on James 3. > > We tried hard to make our development workflow as simple as possible. > > One thing that's very annoying right now is that James is composed of > several git repositories. > > We tried to use "git submodule" to aggregate all James modules into a > parent project. You can see it by yourself here : > https://github.com/linagora/james-parent > > Everything would be ok if James were mature enough to make changes in a > single repository for most fixes and improvements. > > Our experience is that we almost always change several repositories for a > task : adding a test to MPT tests often leads to some fixes in other > modules, adding an implementation for an interface requires some spring > configuration in the main repository, even a maven dependency in a given > repository often breaks other modules when putting everything together. > > With the current layout, our workflow contains some tricky tasks : > > x to create a "global branch", we create a branch for every repository, a > branch for james-parent, then we have to commit everything for james-parent > to point to the right version of submodules. > > x for every single commit, we need to commit james-parent too in order to > follow submodule revision > > x We need several Pull-Requests for a single task, that makes it hard to > reason about changes and it must be applied in the right order > > x Branch merging is painful too > > > While discussing in JIRA (https://issues.apache.org/jira/browse/JAMES-1588), > Eric asked me to come with a proposal about merging some James repositories > together and ask for feedback about Pros and Cons. > > To start, here is the repositories needed to build James : > > jdkim > jsieve > jspf > mime4j > james-project > james > mailbox > mailet > mpt > protocols > > The first four are specialized modules and don't need to change with James > development IMO, so they can live in their own git repository. > > The other 6 (7 if you count the JIRA-1588 proposed "backends" repository) > are very tied together and could be merged into a single git repository > with the following tree : > > james-project > |---- james > |---- mailbox > |---- mailet > |---- mpt > |---- protocols > |---- backends > > We should then make it clear on the website what is a "library" (jdkim, > jsieve, jspf, mime4j) dependency and what is a "server module" (everything > else). > > Here is my opinions about this new organization : > > Pro : > > + Faster dev for cross-module developments > + Merge integration testing (MPT) to the main repository > + Less build ordering issues when merging changes in two modules > + Easier "Getting Start" (git clone, mvn compile) > + Easier Tagging/Release > > Con : > > - Slower "mvn package" > - Every modules have to evolve accordingly to prevent build failure > > Feel free to add your opinion to this proposal. > > -- > Matthieu Baechler > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > >
