robert burrell donkin ha scritto:
On 2/10/07, Stefano Bagnara <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
