You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Stefano Bagnara <ap...@bago.org> on 2008/08/10 19:13:12 UTC
[server.trunk] modules/package refactoring UPDATE
Stefano Bagnara ha scritto:
> After I moved tests in the right places (excluding IMAP), I'd like to
> sort out a better structure for our modules.
> [...]
> I don't want to make a proposal for each change because it would take
> too much time, and I cannot know what to propose until I put my hands on
> the code.
>
> Let me know if you want me to do this and how to proceed (work in trunk,
> create a branch, work on my disk and put a big zip with the result in a
> JIRA issue, do nothing).
It's a week since this mail and no answer (well, it's mid-august, maybe
everyone is on holiday), so I decided to go ahead and simply work in
trunk, as CTR suggests in this cases. A branch does not seems to be
appropriate because Robert doesn't like dev-branches, so here is my attempt.
Don't take this as pushing. If anyone think this is wrong we can
revert/branch or do anything else as soon as someone else will become
active again. Feel free to revert anything I did if this block you doing
anything.
Here is a status update:
I completed my first step in "repackaging" and "remoduling" server.trunk
code.
It is far from being perfect, but at least a first goal is achieved.
Now no package belong to 2 modules considering -util, -api and -library
modules.
Here are the current modules and their packages:
==============================================================
mailnotification.util --------> o.a.j.util.mail.*
common.util ------------------> o.a.j.util
o.a.j.util.io
o.a.j.util.sql
o.a.j.util.stream
user-api ---------------------> o.a.j.api.user.*
o.a.j.api.vut.*
domain-api -------------------> o.a.j.api.dnsservice.*
o.a.j.api.domainlist.*
imap-api ---------------------> o.a.j.api.imap.*
imap-codec-library -----------> o.a.j.imapserver.codec.*
o.a.j.imap.message.*
o.a.j.imap.command.imap4rev1.*
user-library -----------------> o.a.j.impl.jamesuser.*
o.a.j.impl.user.*
o.a.j.impl.vut.*
avalon-spring-bridge-library -> o.a.j.container.spring.*
avalon-socket-library --------> o.a.j.socket.*
o.a.j.util.watchdog.*
o.a.j.util.connection.*
mailbox-library --------------> o.a.j.mailboxmanager.*
core-library -----------------> o.a.j.core
o.a.j.dnsserver
o.a.j.domain
o.a.j.mailrepository.*
o.a.j.management.*
o.a.j.services.*
o.a.j
o.a.j.util.bayesian.*
o.a.j.util.codec.*
o.a.j.util.dbcp.*
o.a.j.util.dnsservice.*
o.a.j.util.scheduler.*
==============================================================
The next steps (as soon as I find the cycles) are:
1. core-library: split it into multiple modules, repackage content to
avoid use of the "generic" packages.
2. take care of packages in functions: they must not reuse packages
already used by api/util/libraries.
The ant build is working... m2 build have some dependency issues
(dependencies are declared in a more granular way in m2, so I don't
update it at each refactoring).
I did not check yet if the resulting binary distribution is still
working. Unless someone has hurry to check other things I'll this after
the 2 above steps (it's likely I missed some xml/xinfo file update
during the refactoring).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [server.trunk] modules/package refactoring UPDATE
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 8/12/08, Danny Angus <da...@apache.org> wrote:
> Well done, and thanks for the clear update, this was good to read. :-)
> i've just got the code and will have a look at it later, but it sounds
> like a good job.
+1
- Robert
>
> On 8/11/08, Stefano Bagnara <ap...@bago.org> wrote:
>> Stefano Bagnara ha scritto:
>>> I completed my first step in "repackaging" and "remoduling" server.trunk
>>> code.
>>> It is far from being perfect, but at least a first goal is achieved.
>>> Now no package belong to 2 modules considering -util, -api and -library
>>> modules.
>>> [...]
>>> The next steps (as soon as I find the cycles) are:
>>> 1. core-library: split it into multiple modules, repackage content to
>>> avoid use of the "generic" packages.
>>> 2. take care of packages in functions: they must not reuse packages
>>> already used by api/util/libraries.
>>
>> Here we are at the end of my second day on this "sprint".
>>
>> I moved around some more code and main changes are:
>>
>> A. Packages should no more be repeated in api/libraries/util.
>>
>> B. No package used by api/libraries/util is used in functions (A+B means
>> that I'm not sure if we have functions using the same packages)
>>
>> C. Renamed mailnotification-util to javamail-util (at the end of the 2
>> days refactoring it made more sense because of dependencies/content).
>>
>> D. Introduced core-api to contain basic service interfaces
>> (org.apache.james.services) from core-library. (I also moved some of
>> org.apache.james.services to functions when they were not used by other
>> modules).
>>
>> E. Introduced a management-library module to contain management stuff
>> (after I refactored code to be selfcontained in that package). Only
>> RemoteManager-function currently depends on this.
>>
>> F. Introduced a core-function module to host all of the code from
>> core-library that was not used by other functions and reduce the size of
>> this core-library as it already is the most used dependency.
>>
>> I don't plan further major changes after this one, but I have to take
>> the time to review the resulting structure with my tools.
>>
>> There are still some utilities in core-library that should be checked.
>> I still have issues with some module "granularization" but I can't see a
>> better solution now. The main goal of this was packages separation and
>> smaller core-library.
>>
>> Currently hudson fail because of svn issues I have to investigate. I'm
>> not sure if the ant/m2 builds works now and if the resulting binary
>> works. I'm testing this now.
>>
>> I don't know what's next.. I have to relax and look at the "new" tree
>> after cooling down.
>>
>> Please review and tell if you see improvement over the previous tree or
>> you prefer to revert this 2 days big-bang.
>>
>> Stefano
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>
> --
> Sent from Google Mail for mobile | mobile.google.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [server.trunk] modules/package refactoring UPDATE
Posted by Danny Angus <da...@apache.org>.
Well done, and thanks for the clear update, this was good to read. :-)
i've just got the code and will have a look at it later, but it sounds
like a good job.
On 8/11/08, Stefano Bagnara <ap...@bago.org> wrote:
> Stefano Bagnara ha scritto:
>> I completed my first step in "repackaging" and "remoduling" server.trunk
>> code.
>> It is far from being perfect, but at least a first goal is achieved.
>> Now no package belong to 2 modules considering -util, -api and -library
>> modules.
>> [...]
>> The next steps (as soon as I find the cycles) are:
>> 1. core-library: split it into multiple modules, repackage content to
>> avoid use of the "generic" packages.
>> 2. take care of packages in functions: they must not reuse packages
>> already used by api/util/libraries.
>
> Here we are at the end of my second day on this "sprint".
>
> I moved around some more code and main changes are:
>
> A. Packages should no more be repeated in api/libraries/util.
>
> B. No package used by api/libraries/util is used in functions (A+B means
> that I'm not sure if we have functions using the same packages)
>
> C. Renamed mailnotification-util to javamail-util (at the end of the 2
> days refactoring it made more sense because of dependencies/content).
>
> D. Introduced core-api to contain basic service interfaces
> (org.apache.james.services) from core-library. (I also moved some of
> org.apache.james.services to functions when they were not used by other
> modules).
>
> E. Introduced a management-library module to contain management stuff
> (after I refactored code to be selfcontained in that package). Only
> RemoteManager-function currently depends on this.
>
> F. Introduced a core-function module to host all of the code from
> core-library that was not used by other functions and reduce the size of
> this core-library as it already is the most used dependency.
>
> I don't plan further major changes after this one, but I have to take
> the time to review the resulting structure with my tools.
>
> There are still some utilities in core-library that should be checked.
> I still have issues with some module "granularization" but I can't see a
> better solution now. The main goal of this was packages separation and
> smaller core-library.
>
> Currently hudson fail because of svn issues I have to investigate. I'm
> not sure if the ant/m2 builds works now and if the resulting binary
> works. I'm testing this now.
>
> I don't know what's next.. I have to relax and look at the "new" tree
> after cooling down.
>
> Please review and tell if you see improvement over the previous tree or
> you prefer to revert this 2 days big-bang.
>
> Stefano
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
--
Sent from Google Mail for mobile | mobile.google.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [server.trunk] modules/package refactoring UPDATE
Posted by Stefano Bagnara <ap...@bago.org>.
Stefano Bagnara ha scritto:
> I completed my first step in "repackaging" and "remoduling" server.trunk
> code.
> It is far from being perfect, but at least a first goal is achieved.
> Now no package belong to 2 modules considering -util, -api and -library
> modules.
> [...]
> The next steps (as soon as I find the cycles) are:
> 1. core-library: split it into multiple modules, repackage content to
> avoid use of the "generic" packages.
> 2. take care of packages in functions: they must not reuse packages
> already used by api/util/libraries.
Here we are at the end of my second day on this "sprint".
I moved around some more code and main changes are:
A. Packages should no more be repeated in api/libraries/util.
B. No package used by api/libraries/util is used in functions (A+B means
that I'm not sure if we have functions using the same packages)
C. Renamed mailnotification-util to javamail-util (at the end of the 2
days refactoring it made more sense because of dependencies/content).
D. Introduced core-api to contain basic service interfaces
(org.apache.james.services) from core-library. (I also moved some of
org.apache.james.services to functions when they were not used by other
modules).
E. Introduced a management-library module to contain management stuff
(after I refactored code to be selfcontained in that package). Only
RemoteManager-function currently depends on this.
F. Introduced a core-function module to host all of the code from
core-library that was not used by other functions and reduce the size of
this core-library as it already is the most used dependency.
I don't plan further major changes after this one, but I have to take
the time to review the resulting structure with my tools.
There are still some utilities in core-library that should be checked.
I still have issues with some module "granularization" but I can't see a
better solution now. The main goal of this was packages separation and
smaller core-library.
Currently hudson fail because of svn issues I have to investigate. I'm
not sure if the ant/m2 builds works now and if the resulting binary
works. I'm testing this now.
I don't know what's next.. I have to relax and look at the "new" tree
after cooling down.
Please review and tell if you see improvement over the previous tree or
you prefer to revert this 2 days big-bang.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [server.trunk] modules/package refactoring UPDATE
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Aug 10, 2008 at 6:13 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Stefano Bagnara ha scritto:
>>
>> After I moved tests in the right places (excluding IMAP), I'd like to sort
>> out a better structure for our modules.
>> [...]
>> I don't want to make a proposal for each change because it would take too
>> much time, and I cannot know what to propose until I put my hands on the
>> code.
>>
>> Let me know if you want me to do this and how to proceed (work in trunk,
>> create a branch, work on my disk and put a big zip with the result in a JIRA
>> issue, do nothing).
>
> It's a week since this mail and no answer (well, it's mid-august, maybe
> everyone is on holiday), so I decided to go ahead and simply work in trunk,
> as CTR suggests in this cases. A branch does not seems to be appropriate
> because Robert doesn't like dev-branches, so here is my attempt.
>
> Don't take this as pushing. If anyone think this is wrong we can
> revert/branch or do anything else as soon as someone else will become active
> again. Feel free to revert anything I did if this block you doing anything.
cool
> Here is a status update:
>
> I completed my first step in "repackaging" and "remoduling" server.trunk
> code.
> It is far from being perfect, but at least a first goal is achieved.
> Now no package belong to 2 modules considering -util, -api and -library
> modules.
sounds great
> Here are the current modules and their packages:
> ==============================================================
> mailnotification.util --------> o.a.j.util.mail.*
> common.util ------------------> o.a.j.util
> o.a.j.util.io
> o.a.j.util.sql
> o.a.j.util.stream
> user-api ---------------------> o.a.j.api.user.*
> o.a.j.api.vut.*
> domain-api -------------------> o.a.j.api.dnsservice.*
> o.a.j.api.domainlist.*
> imap-api ---------------------> o.a.j.api.imap.*
> imap-codec-library -----------> o.a.j.imapserver.codec.*
> o.a.j.imap.message.*
> o.a.j.imap.command.imap4rev1.*
> user-library -----------------> o.a.j.impl.jamesuser.*
> o.a.j.impl.user.*
> o.a.j.impl.vut.*
> avalon-spring-bridge-library -> o.a.j.container.spring.*
> avalon-socket-library --------> o.a.j.socket.*
> o.a.j.util.watchdog.*
> o.a.j.util.connection.*
> mailbox-library --------------> o.a.j.mailboxmanager.*
> core-library -----------------> o.a.j.core
> o.a.j.dnsserver
> o.a.j.domain
> o.a.j.mailrepository.*
> o.a.j.management.*
> o.a.j.services.*
> o.a.j
> o.a.j.util.bayesian.*
> o.a.j.util.codec.*
> o.a.j.util.dbcp.*
> o.a.j.util.dnsservice.*
> o.a.j.util.scheduler.*
> ==============================================================
>
> The next steps (as soon as I find the cycles) are:
> 1. core-library: split it into multiple modules, repackage content to
> avoid use of the "generic" packages.
> 2. take care of packages in functions: they must not reuse packages
> already used by api/util/libraries.
>
> The ant build is working... m2 build have some dependency issues
> (dependencies are declared in a more granular way in m2, so I don't update
> it at each refactoring).
> I did not check yet if the resulting binary distribution is still working.
> Unless someone has hurry to check other things I'll this after the 2 above
> steps (it's likely I missed some xml/xinfo file update during the
> refactoring).
thanks for letting us know what's happening. i'll probably have more
feedback once i've taken a look at the code.
- robert
>
> Stefano
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org