james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthieu Baechler <mbaech...@linagora.com>
Subject Re: Proposal about James modules merge
Date Tue, 01 Sep 2015 07:18:36 GMT
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-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message