james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: phoenix-deployment tests status
Date Mon, 04 Aug 2008 17:20:39 GMT
Robert Burrell Donkin ha scritto:
> 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.

Why? I won't push a release with or without IMAP, but I don't see why 
you have to separate IMAP in order to cut a milestone from trunk. BTW 
this is just my opinion, and my -0 won't stop anyone from going forward.
It does not worth to keep reiterating that we have different opinions on 
this. If you plan to actually release something, please let me know what 
I can do to increase the chance of success. I can help if I know the plan.

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

I would like to believe in you and claim the codebase is guilty for 
JAMES issues.. I'm trying to help with the codebase.. I really hope you 
are right.

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

Well, we had 1 developer on mime4j and he refused to join us as a 
committer... I don't think it is good to take this as a proof that small 
codebases bring us more developers.
Between 2005 and 2006 we had Bernd, Norman, Joachim and me joining this 
project to work on james-server big/bad codebase.

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

+1 I try to do this all the time, all the way. I also think that user 
support is a good thing for this. We have many java developers in our 
small user-base, helping them increase the chance they will take the 
time to tweak james too.

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

5 minutes on my laptop using maven.
IMHO releases and features attract more developers than any kind of 
small/large/bautiful codebase. But I already tried with this and failed, 
so I'm not entitled in pushing this concept.

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

IN my opinion there is much more users for an smtp server than for a 
protocol library. At least this is my impression by lurking JAMES lists 
since years.

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

+1 what's the blocker for this?


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

View raw message