james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Brewin <sbre...@apache.org>
Subject Re: Proposal about James modules merge
Date Thu, 27 Aug 2015 16:17:02 GMT
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-indendendant 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 no 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


Mime
View raw message