On 2015-09-03 15:13, Matthieu Baechler wrote:
On 03/09/2015 11:48, Eric Charles wrote:
On 2015-09-03 11:04, Matthieu Baechler wrote:
Hi Eric,
On 03/09/2015 10:16, Eric Charles wrote:
I like Matthieu proposal (merge without mime4...), but this will open
the door to more refactoring that would maybe go against the initial
requirement of being able to embed some mailbox without the full
server.
Of course, as the mailbox API will probably change more often, it will
break potential mailbox-api direct users. It leads to two questions :
- is there such users ?
- do we expect alpha/beta software to be API stable ?
I really like the idea of merging things until 3.0 release happens then
decide if we split back or not.
If we merge, we should be sure this is the right thing to do before and
after 3.0.
Why would we split again after 3.0?
Because maybe when you have a 3.0 release, the project goal can change
from "releasing a great mail server" to "trying to grow a contributor
community" or anything else.
Stefano first talk about this idea:
"And maybe they could be merged until we get to a more stable solution,
and then splitted again once they are stable enough."
I don't see anything wrong in using the right process for a given goal.
Thx for the clarification.
Maybe we should write to guidelines we can refer when working in that
single repository, otherwise we will have endless discussions that
don't
occur for now simply because code live in separate projects.
I think maven dependencies capture the intent of module responsibility
very well. What would you want the guidelines to contain ? API stability
rules ? Anything else ?
Classes, Packages, Maven submodules and repositories all serve IMHO
segregation of responsibility and API.
For now, we have hard barrier that prevent someone to break this.
I don't see anything we would loose once the repositories are merged.
What prevent any commiter to add spring into data-api today ? Or to
introduce a cyclic dependency ?
Maybe I don't understand what you mean by "hard barrier", do you have
some examples ?
I will be (a bit) easier to refactor in a wrong way when everything will
be in the same repository. But it is true that it is already possible to
take a wrong road with the current structure.
I was thinking more about a documented diagram such as the one I started
on http://james.apache.org/server/3/dev.html to show the modules
interactions and boundaries.
A common understanding of such a representation will ease later
discussion.
Actually, I don't see how the merge impact this diagram. We can
definitively improve it, if it's what you mean, but is it really related
to the merge ?
It does not and the documentation should not be a requirement to merge.
+1 on the principle of your merge proposal.
On the details, I would rename 'james' by 'server', and 'backend' with
something else ('persistence', 'common', 'util'...?, it depends what you
anticipate to come into)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
