On 3/22/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
40 days passed without comments/opinions so today I found a bit of time
to experiment with the modular build system and I committed it.
I extracted a mailet-api module and the mailet-library module from the
phoenix-deployment and it worked fine.
great :-)
Then I moved all of the source code (escluding Main.java) to the
core-library module. I had to move to core-library/build.xml the
Constants.java properties based source pre-processing.
I also had to add hacks because this code depends on mailet-library
module but being it a library itself was not possible to depends on it.
Then I extracted most of the functions modules in their own folder:
smtpserver, pop3server, fetchmail, nntpserver, remotemanager, imapserver
and spoolmanager (maybe to be splitten in mailetcontainer/transport)
worked out of the box.
Running ant from the root did not work because the default target is
"lite" and it expects modules to be already built and only run
deployments, so I switched the default target to Full.
i suspected that this might need tuning
there are two general schools of thought
Please review the commits and let me know if this is what you intended
with your proposal.
it's not so much what i intended but whether i can see any improvements :-)
i planned to spend this weekend working on the modularisation so
expect more comments then
I have a bunch of problems to proceed:
1) we can reorganize stuff but libraries will depends on other
libraries: how can we manage intra-libraries dependencies? We will
refactor when we have cross-dependency but we cannot avoid simple
dependency. The same apply to APIs (e.g: the MailRepository apis depends
on the Mailet apis). We will probably need an "util/common" library to
be imported by every other library, too.
i'd hoped that we could avoid a complex dependency graph by dividing
into broad layers with standard dependencies between layers. i'll take
a look at the codebase this weekend and see whether this is
reasonable.
2) How should we manage javadocs creation and sdk creation in this
multimodule structure? I think the "move" broke them.
it's easy to put them back again but i'd prefer to hear opinions
before i implement
one approach is for all modules to create src and javadoc jars of
their own (useful for IDEs) and then unpack them in deploy. another is
to javadoc from the deployment across all modules.
Once this steps are solved the following step is to split the
core-library into multiple libraries and to move around 3-4 classes
belonging to function-modules packages but we need them in the libraries.
not sure i understand this. i'll take a look at the code and ask if it
still isn't clear...
Once we are done with this we should try to isolate the use of avalon
from the api/library layer and isolate it to the function modules.
The last step is to refactor the function modules to move the avalon
stuff into a specific avalon-deployment module and the
phoenix-deployment will depend on this module (we need intra module
dependency here too).
i took a look at the avalon coupling. IIRC the major issue is going to
be logging.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
