On 3/23/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
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'm very, very happy for other people to jump in :-)
too many projects: too little energy
>> 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.
yep
<snip>
>> 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.
+1
i'd like to see the core interfaces and associated classes pulled out
from core-library into a core-api
hopefully this might allow the implementations to be split up in to
separate libraries or functions.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
