Thank you for your answer Stephen. It looks like we agree one this proposal.
Can I take your answer for a +1 ?
Eric : you didn't gave your opinion yet, WDYT ?
--
Matthieu Baechler
On 27/08/2015 20:02, Stephen Brewin wrote:
My previous post corrected for copy/paste issues on phone!
On 27/08/2015 17:17, Stephen Brewin wrote:
On 27/08/2015 10:24, Matthieu Baechler wrote:
Hi Steve,
Thanks for your feedback.
On 27/08/2015 11:11, Stephen Brewin wrote:
Hi
As I recall, the intent of having separate projects for many of the
components developed under the James umbrella was to satisfy the
requirement that they should be independent of James Server. While this
remains a requirement, separate repositories are needed for each
project
to allow separate release versions and schedules. It also influences
our
maven module layout and how dependencies might be better managed.
Before proceeding with a discussion of how to simplify the development
workflow, we need to decide if the original requirement still holds.
Prospective solutions will be quite different depending on this answer.
I think there's always a balance to find between flexibility and
simplicity and we should never loose flexibility when there's nothing
to gain.
That's why I think we should not talk of requirements for "James
Server components" as a whole but to weight for each component what
we can gain and what we would loose.
It's what I tried to do by excluding jdkim, jsieve, jspf and mime4j
from the merge candidates as there's very little to gain IMO (I might
be wrong, of course).
I would really like the community to tell me what are the cases where
the other components could benefit from being separated, that would
help answering the question "do we want to change the requirements" ?
Cheers,
Hi Matthieu
At the moment the separate projects are only semi-independent which
gives rise to workflow and dependency problems. They should either be:
* Entirely independent, maintained separately from James server and
James server should treat them no differently to other 3rd party
artefacts
* Sub-modules of James server, sharing the same repository, version
numbers and dependency library (via a BOM), thereby easing the
workflow and dependency problems
/If we switch to the sub-module approach the separate maven artefacts
would still be available to 3rd parties, which I believe captures the
original intent of the requirement./
Theoretically, separate projects allow each to follow a more nimble
release cycle than James server, but recent years have shown little
evidence in support of this.
Cheers
--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
