robert burrell donkin ha scritto:
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
Well, I have no strong preferences. My only request is that "ant" from
an out-of-the-box checkout should be able to build our artifacts.
So either we commit snapshots jars of the modules so that ant will
simply "combine" them into the final artifact or we use the full goal or
we at least use lazy building of the modules.
In the mean time the "full" solves the nighly build issue.
[..]
i planned to spend this weekend working on the modularisation so
expect more comments then
I hope I didn't "steal" some task you already planned to do. If this is
the case feel free to revert my experiments and apply "your way" :-)
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.
Maybe we can solve this once we move the mailet-api into its own
project. But this must be investigated while splitting/moving modules.
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.
I prefer to have each jar with its own javadocs, and maybe we can unpack
them all in a single package in the final distribution, but I don't know
if this is easy to do.
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...
We have some class from imapserver.debug package used in the core
package. We have classes from fetchmail package used in core lib. If you
look at the current structure I left them in their original package but
I moved them to the right module, but, as you suggested, having splitted
packages is no good, so it is better to move them into different packages.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
