[RESULT] [PROPOSAL] steps 1.1 and 1.2 towards server modularisation

[robert burrell donkin <ro...@gmail.com>]

On 2/4/07, robert burrell donkin <ro...@gmail.com> wrote:
> there seems to be a rough consensus in favour of modularising james.
> i've pulled together a document about one possible design
> (http://wiki.apache.org/james/Development/Modularisation). this is
> just one possible direction but this proposal is only about the first
> step towards modularization. please start discussions about this
> design on a separate thread.
>
> i'm convinced that modularisation is crucial for both technical and
> community reasons. i hope that we can start down this roads whilst
> discussing some of the later details.
>
> the most disruptive step will be pushing the existing codebase into a
> subdirectory. IHMO for this, RTC is more appropriate than CTR. the
> proposal is the first step towards modularisation: moving the existing
> server code into a subdirectory so that other modules can be created
> at the same level.
>
> i'm willing to implement. unless people jump in, I plan to execute on
> saturday 11th feburary but this timing is not part of this proposal.
>
> i will tally this vote no earlier than 2400 GMT on wednesday, 7th Feburary

i count

+1 robert burrell donkin
+1 Stefano Bagnara
+1 Norman Maurer

seems like a reasonable consensus to me so unless anyone jumps in i'll
execute on this saturday (10th)

- robert

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

Re: Server modularisation and directory layout questions

[robert burrell donkin <ro...@gmail.com>]

On 2/10/07, Stefano Bagnara <ap...@bago.org> wrote:
> robert burrell donkin ha scritto:
> > On 2/10/07, Stefano Bagnara <ap...@bago.org> wrote:
> >> On phase 3 you wrote:
> >> "create stage subdirectory which is local only": can you give more
> >> details? I didn't understand what "is local only" means (is this related
> >> to ant-1.7?)
> >
> > nope: subversion
> >
> > each module needs a build for that module that is self-contained.
> > modules are going to have dependencies so we need an area containing
> > jars for dependent modules. this is what i meant by a staging area.
>
> Ok, this is the equivalent of the maven (-snapshot) repository, right?
> Again it would be cool if we use a structure compatible with maven: the
> legacy structure I previously referenced is the simpler to use with
> other tools.

i'm agnostic

opinions?

> >> Can I also ask you what are the modules you plan to split?
> >>
> >> E.g:
> >> Build Modules
> >> - Is the "stage directory" something you put here?
> >
> > nope
> >
> > efficient multi-module ant means rolling a custom antlib
>
> Ok. I expected there was more in core ant 1.7 and that we didn't need to
> write too much ant specific code (but reading phase3 and 4 I understand
> I was wrong).

more likely to be macros and common build scripts (imported by each
module) than code. this avoids having to maintain complete builds for
each module.

- robert

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

Re: Server modularisation and directory layout questions

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

robert burrell donkin ha scritto:
> On 2/10/07, Stefano Bagnara <ap...@bago.org> wrote:
>> On phase 3 you wrote:
>> "create stage subdirectory which is local only": can you give more
>> details? I didn't understand what "is local only" means (is this related
>> to ant-1.7?)
> 
> nope: subversion
> 
> each module needs a build for that module that is self-contained.
> modules are going to have dependencies so we need an area containing
> jars for dependent modules. this is what i meant by a staging area.

Ok, this is the equivalent of the maven (-snapshot) repository, right?
Again it would be cool if we use a structure compatible with maven: the 
legacy structure I previously referenced is the simpler to use with 
other tools.

>> Can I also ask you what are the modules you plan to split?
>>
>> E.g:
>> Build Modules
>> - Is the "stage directory" something you put here?
> 
> nope
> 
> efficient multi-module ant means rolling a custom antlib

Ok. I expected there was more in core ant 1.7 and that we didn't need to 
write too much ant specific code (but reading phase3 and 4 I understand 
I was wrong).

>> Function Modules
>> - smtpserver
>> - pop3server
>> - fetchmail
>> - remotemanager
>> - nntpserver
>> - imapserver
>> - transport (maybe to be named spoolmanager)
>> - mailetcontainer: to contain the James.java and some of the
>> transport/*loader* stuff.
> 
> sounds reasonable
> 
> (i intend to put the framework in place and let the community split
> out functional modules)

I bet I will really enjoy this new structure!

>> Library Modules
>> - usersrepository
>> - mailrepository
>> - mailboxmanager
>> - dnsserver
>> - vut
>> - domain
>> - management
> 
> sounds reasonable
> 
> again, the list is something that i'd hope that would emerge

This will make much more clear to anyone what are the dependencies in 
the code and will be much more easy for newbies to work on specific 
parts of the code without understanding the full architecture!

>> Is this something that matches your proposal or had I misunderstood you?
> 
> close enough :-)

*wonderful* :-)

>> Maybe this is too premature (so feel free to ignore/delay if this is far
>> in your plans): for every function and library module we have "core"
>> code and avalon component declarations + avalon wrappers to wire
>> services: do you think the road is to split them in "core"+"avalon"
>> sub-modules?
> 
> not premature at all: in fact, kick-starting a discussion was the intention

Thinking a bit more about this I guess that it would probably be better 
to put all of the avalon wrappers in the phoenix-deployment or maybe 
even better to create an avalon-deployment (or avalon-components) module 
that is used by the phoenix-deployment. Otherwise we introduce too much 
chaos/granularity with "single class modules".

Stefano


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

Re: Server modularisation and directory layout questions

[robert burrell donkin <ro...@gmail.com>]

On 2/10/07, Stefano Bagnara <ap...@bago.org> wrote:
> robert burrell donkin ha scritto:
> > On 2/4/07, robert burrell donkin <ro...@gmail.com> wrote:
> >> there seems to be a rough consensus in favour of modularising james.
> >> i've pulled together a document about one possible design
> >> (http://wiki.apache.org/james/Development/Modularisation). this is
> >> just one possible direction but this proposal is only about the first
> >> step towards modularization. please start discussions about this
> >> design on a separate thread.
>
> On phase 3 you wrote:
> "create stage subdirectory which is local only": can you give more
> details? I didn't understand what "is local only" means (is this related
> to ant-1.7?)

nope: subversion

each module needs a build for that module that is self-contained.
modules are going to have dependencies so we need an area containing
jars for dependent modules. this is what i meant by a staging area.

> Can I also ask you what are the modules you plan to split?
>
> E.g:
> Build Modules
> - Is the "stage directory" something you put here?

nope

efficient multi-module ant means rolling a custom antlib

> Deployment Modules
> - phoenix-deployment: contains what we currently have in phoenix-bin and
> the necessary ant task to build our current binary distribution.
> - spring-deployment

yep

> Function Modules
> - smtpserver
> - pop3server
> - fetchmail
> - remotemanager
> - nntpserver
> - imapserver
> - transport (maybe to be named spoolmanager)
> - mailetcontainer: to contain the James.java and some of the
> transport/*loader* stuff.

sounds reasonable

(i intend to put the framework in place and let the community split
out functional modules)

> Library Modules
> - usersrepository
> - mailrepository
> - mailboxmanager
> - dnsserver
> - vut
> - domain
> - management

sounds reasonable

again, the list is something that i'd hope that would emerge

> API Module
> - mailet-api (candidate to be moved in its own product repository at the
> same level of server, jspf, mime4j)

IMHO move into it's own repository

> - mailet (maybe to be placed in the mailet-api product, too.. ?!)

unsure

> - james-api: contains the "services" packages and maybe something more?

sounds reasonable

> Single module containing the core James API
> - core: the current content of core+util+context+security
>
> Is this something that matches your proposal or had I misunderstood you?

close enough :-)

> Maybe this is too premature (so feel free to ignore/delay if this is far
> in your plans): for every function and library module we have "core"
> code and avalon component declarations + avalon wrappers to wire
> services: do you think the road is to split them in "core"+"avalon"
> sub-modules?

not premature at all: in fact, kick-starting a discussion was the intention

> I would add a "personal request" to be considered while we move so much
> stuff around and we work on build scripts and so on:
>
> 1) Adopt SDL for module directory layouts:
> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>
> 2) Organize the lib folder like a legacy maven1 repository (like we did
> in jSPF):
> - from: lib/#artifactname#[-#artifactversion#].jar
> - to: lib/#artifactgroup#/jars/#artifactname#-#artifactversion#.jar
>
> This 2 tasks should not complicate the ant build and give us much more
> agility mantaining the poms to build the website: WDYT?

i'm agnostic

opinions?

> PS: if I misunderstood you and this is not your plan I don't want to
> make you loose too much time explaining me things, so feel free to
> simply say "No, just shut up and wait for details when I will provide
> new proposals" ;-)

my plan was to kick start the modularization and let everyone help to
work out the details so this fits in nicely :-)

- robert

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

Server modularisation and directory layout questions

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

robert burrell donkin ha scritto:
> On 2/4/07, robert burrell donkin <ro...@gmail.com> wrote:
>> there seems to be a rough consensus in favour of modularising james.
>> i've pulled together a document about one possible design
>> (http://wiki.apache.org/james/Development/Modularisation). this is
>> just one possible direction but this proposal is only about the first
>> step towards modularization. please start discussions about this
>> design on a separate thread.

On phase 3 you wrote:
"create stage subdirectory which is local only": can you give more 
details? I didn't understand what "is local only" means (is this related 
to ant-1.7?)

Can I also ask you what are the modules you plan to split?

E.g:
Build Modules
- Is the "stage directory" something you put here?

Deployment Modules
- phoenix-deployment: contains what we currently have in phoenix-bin and 
the necessary ant task to build our current binary distribution.
- spring-deployment

Function Modules
- smtpserver
- pop3server
- fetchmail
- remotemanager
- nntpserver
- imapserver
- transport (maybe to be named spoolmanager)
- mailetcontainer: to contain the James.java and some of the 
transport/*loader* stuff.

Library Modules
- usersrepository
- mailrepository
- mailboxmanager
- dnsserver
- vut
- domain
- management

API Module
- mailet-api (candidate to be moved in its own product repository at the 
same level of server, jspf, mime4j)
- mailet (maybe to be placed in the mailet-api product, too.. ?!)
- james-api: contains the "services" packages and maybe something more?

Single module containing the core James API
- core: the current content of core+util+context+security

Is this something that matches your proposal or had I misunderstood you?

Maybe this is too premature (so feel free to ignore/delay if this is far 
in your plans): for every function and library module we have "core" 
code and avalon component declarations + avalon wrappers to wire 
services: do you think the road is to split them in "core"+"avalon" 
sub-modules?

I would add a "personal request" to be considered while we move so much 
stuff around and we work on build scripts and so on:

1) Adopt SDL for module directory layouts:
http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

2) Organize the lib folder like a legacy maven1 repository (like we did 
in jSPF):
- from: lib/#artifactname#[-#artifactversion#].jar
- to: lib/#artifactgroup#/jars/#artifactname#-#artifactversion#.jar

This 2 tasks should not complicate the ant build and give us much more 
agility mantaining the poms to build the website: WDYT?


Stefano

PS: if I misunderstood you and this is not your plan I don't want to 
make you loose too much time explaining me things, so feel free to 
simply say "No, just shut up and wait for details when I will provide 
new proposals" ;-)


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