phoenix-deployment tests status

[Stefano Bagnara <ap...@bago.org>]

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?

Stefano

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

Re: phoenix-deployment tests status

[Robert Burrell Donkin <ro...@gmail.com>]

On Mon, Aug 4, 2008 at 6:20 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Mon, Aug 4, 2008 at 4:16 PM, Stefano Bagnara <ap...@bago.org> wrote:

<snip>

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

release manager for jsieve (jsieve is first in line)

i don't have a release environment i trust any more. norman's very
good and i had hoped he might be able to find the time. i might need
to find the time to set one up...

- robert

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

Re: phoenix-deployment tests status

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> On Mon, Aug 4, 2008 at 4:16 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On 8/1/08, Stefano Bagnara <ap...@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?

Stefano

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

Re: phoenix-deployment tests status

[Robert Burrell Donkin <ro...@gmail.com>]

On Mon, Aug 4, 2008 at 4:16 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On 8/1/08, Stefano Bagnara <ap...@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

Re: phoenix-deployment tests status

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> On 8/1/08, Stefano Bagnara <ap...@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).

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

Stefano


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

Re: phoenix-deployment tests status

[Robert Burrell Donkin <ro...@gmail.com>]

On 8/1/08, Stefano Bagnara <ap...@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, 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.

Robert

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