james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: phoenix-deployment tests status
Date Mon, 04 Aug 2008 17:01:56 GMT
On Mon, Aug 4, 2008 at 4:16 PM, Stefano Bagnara <apache@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On 8/1/08, Stefano Bagnara <apache@bago.org> wrote:
>>>
>>> Hi all,
>>>
>>> I've moved most tests from the phoenix-deployment module to the module
>>> of the class they was testing.
>>>
>>> The only remaining tests are the imap tests.
>>>
>>> THe issue with imap tests is that they depends both on
>>> imapserver-function and torque-mailboxmanager-function.
>>> torque-mailboxmanager-function could be moved down to a library but it
>>> depends on mailbox-library so it cannot be a library (for the ant build
>>> requirement).
>>>
>>> mailbox-library should not have dependencies on the rest of james, so it
>>> could be even named mailbox-api so to be able to rename
>>> torque-mailboxmanager-function to torque-mailboxmanager-library and have
>>> the tests moved to imapserver-function (because imapserver-function
>>> could then depend on torque-mailboxmanager-library).
>>>
>>> WDYT?
>>
>> I have a plan in mind but I had intended to post it as a proposal.
>>
>> IMAP is now approaching the stage where I think it best to
>
>> delete the old implementation
>
> +1
>
>> eliminate the small codependecies remaining outside deployment  and move
>
>> out of server.
>>
>> This would allow a milestone to be cut before I start into refactoring
>
>> the data access, etc
>>
>> I think removing IMAP as a codebase would make JAMES server more
>> approachable and using a static IMAP implementation would increase the
>> likelihood of a milestone for the server.
>
> -0, unless there is a real proposal to cut a milestone without imap and a
> release manager willing to do that. In this case +0 (I still think that a
> milestone should include everything we have in trunk..
> stable/unstable/experimental stuff... user feedback is important
> also/expecially for unstable/experimental stuff).

releasing without IMAP is very easy, just take a branch and delete the
IMAP code. if you want a relaese with IMAP then IMAP needs to be a
separate, decoupled component with independent versioning.

> It's 2 years we talk about the increased "releasability" of what we have in
> the repository, but it's 2 years I don't see real releases. Keep moving code
> around will not make a release to magically happen, simply it will keep us
> busy updating dependencies and build scripts. Ok, this may be funny... but 2
> years are 2 years ;-)

JAMES has major issues with it's codebase and that's reflected in
major divisions in the community. it often takes years to regain lost
momentum.

JAMES needs to attract more developers.  there are good reasons why
the libraries are much more active and attractive to new developers
than the server code. they are easier to understand and aren't
hopelessly entangled with a dead IoC container.

JAMES needs more developers. we need to make it easier for developers
to get involved.

ATM it takes 13 minutes on a fast machine and 20+ minutes on a slower
one to build and test JAMES. this is far too high for an open source
project. IDEs have problems with JAMES. i agree that splitting into
modules hasn't helped this.

there's a lot of interest in protocol components: libraries that can
be used to build mail servers. there's much less developer interest in
monolithic emails servers which are strongly coupled with dead IoC
containers. factoring out the protocols will not only improve the code
structure but will also increase the chances of recruiting new
developers.

once we start releasing the mailets library, this will offer an easier
way for users to start to contribute.

- robert

---------------------------------------------------------------------
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