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/13 13:37:36 UTC
[server.trunk] dependencies visualization
I'd like to share a couple of charts I created yesterday to better
understand the current status.
I created a graph including the dependencies between our modules and
with external jars.
Here is what yED automatically creates by reducing and creating an
automatic left to right "tight" directed dependencies tree for
http://people.apache.org/~bago/server/2008-08-12-server-trunk-modules-full-dependency-tree.gif
THe groups are also automatically created by yEd by using the
"Autogrouping" "Directed Subtrees" option.
Here is a smaller graph created by closing the groups created previously:
http://people.apache.org/~bago/server/2008-08-12-server-trunk-modules-full-dependency-tree-closed.gif
I find it cool how an automatic layout created a clear visualization of
our 3 layers (api, library, function).
I used green for our modules (light for apis, medium for library, dark
for functions) and light azure for the util modules.
I then used red for avalon framework, purple and orage for excalibur and
cornerstone. Blue is for commons-*. Violet is for other james products.
Edges are coloured as the target node, so to easily see what kind of
dependencies each node has by looking at exit edges colours.
It's not perfect (it does not contain all of our dependencies and
classes) but I found it interesting and I wanted to share it.
From this graph we can see that once we remove most
cornerstone/excalibur dependencies by using delegation in
avalon-socket-library the only cornerstone/excalibur dependencies will
be the datasource related ones (cornerstone-datasources-api,
cornerstone-datasources-impl, excalibur-datasource) and the store-api.
ATM core-library, management-library and avalon-socket-library have
direct dependencies on this jars. I'd like to confine them to functions
as a short term goal.
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] dependencies visualization
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Aug 14, 2008 at 2:09 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Wed, Aug 13, 2008 at 12:37 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>>
>>> Here is what yED automatically creates by reducing and creating an
>>> automatic
>>> left to right "tight" directed dependencies tree for
>>>
>>> http://people.apache.org/~bago/server/2008-08-12-server-trunk-modules-full-dependency-tree.gif
>>> [...]
>>> From this graph we can see that once we remove most cornerstone/excalibur
>>> dependencies by using delegation in avalon-socket-library the only
>>> cornerstone/excalibur dependencies will be the datasource related ones
>>> (cornerstone-datasources-api, cornerstone-datasources-impl,
>>> excalibur-datasource) and the store-api. ATM core-library,
>>> management-library and avalon-socket-library have direct dependencies on
>>> this jars. I'd like to confine them to functions as a short term goal.
>>
>> care to expand?
>
> The only library importing datasource stuff from main code (not tests) is:
> BayesianAnalyzerManagement import
> org.apache.avalon.cornerstone.services.datasources.DataSourceSelector;
> This class, along with DomainListManagement, ProcessorManagement and
> SpoolManagement should be repackaged and moved to a function. (***)
> SpoolManagementTest now in core-function should move together with
> SpoolManagement.
> RemoteManagerTest now dependending on DomainListManagement can be easily
> refactored by using a Mock instead of the real implementation.
>
> Cornerstone.store is used by the mailrepository.filepair package that is
> currently in core-library.
> This code could be moved to a function but we have core-function tests and
> avalon-user-function tests depending on this one.
> There are too many integration tests in our unit tests, and this make it
> difficult to move code around.
> Maybe it's been a mistake to move tests from phoenix-deployment to their own
> module when they was integration tests.
IMHO not a mistake but perhaps the move may prove transitory
> I don't like too much having non-phoenix specific tests in the
> phoenix-deployment, maybe we may simply introduce a basic-deployment module
> having no dependencies (no spring, no phoenix) and put there the integration
> tests. (opinion?)
i was thinking about suggesting this
> If we do this then the filepair package can easily be moved to a function,
> too.
>
> Once we confined cornerstone/excalibur to functions we have 2 roads to
> follow
> 1) remove also avalon-framework from libraries (not a big priority for me)
> 2) create alternative functions (having no cornerstone/excalibur
> dependency).
> Working on this we'll probably have to extract some code from the
> functions to libraries so to be able to reuse some of that code and there
> will probably be a bit of work in moving down "generic" code having no
> dependencies, but we will be able to approach each function as a separate
> task.
>
> The protocol functions are probably the first functions to be interested by
> #2 and your proposal to extract the protocol code to libraries perfectly
> matches this roadmap.
yes
> ***: the real fact is that we should move management apis/interfaces to a
> management-api module and the "impl" classes I'm talking about should be
> refactored to be cornerstone/excalibur free (most time they don't need it,
> it is only an hack to avoid the dependency injection way) and in a library.
> Maybe we can now move up to library/functions and then move down later.
> I don't have issues moving stuff up and down as long as we stay in a single
> product.
the protocols deserve to be released as independent products. it will
also make the remaining code more accessible.
i plan to start moving IMAP into a separate product this weekend. (by
this, i mean the complete IMAP complex including all the mailbox
stuff.) since developing on trunk is impossible for me now, i'll take
a copy into sandbox and start pruning there.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [server.trunk] dependencies visualization
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Wed, Aug 13, 2008 at 12:37 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Here is what yED automatically creates by reducing and creating an automatic
>> left to right "tight" directed dependencies tree for
>> http://people.apache.org/~bago/server/2008-08-12-server-trunk-modules-full-dependency-tree.gif
>> [...]
>> From this graph we can see that once we remove most cornerstone/excalibur
>> dependencies by using delegation in avalon-socket-library the only
>> cornerstone/excalibur dependencies will be the datasource related ones
>> (cornerstone-datasources-api, cornerstone-datasources-impl,
>> excalibur-datasource) and the store-api. ATM core-library,
>> management-library and avalon-socket-library have direct dependencies on
>> this jars. I'd like to confine them to functions as a short term goal.
>
> care to expand?
The only library importing datasource stuff from main code (not tests) is:
BayesianAnalyzerManagement import
org.apache.avalon.cornerstone.services.datasources.DataSourceSelector;
This class, along with DomainListManagement, ProcessorManagement and
SpoolManagement should be repackaged and moved to a function. (***)
SpoolManagementTest now in core-function should move together with
SpoolManagement.
RemoteManagerTest now dependending on DomainListManagement can be easily
refactored by using a Mock instead of the real implementation.
Cornerstone.store is used by the mailrepository.filepair package that is
currently in core-library.
This code could be moved to a function but we have core-function tests
and avalon-user-function tests depending on this one.
There are too many integration tests in our unit tests, and this make it
difficult to move code around.
Maybe it's been a mistake to move tests from phoenix-deployment to their
own module when they was integration tests.
I don't like too much having non-phoenix specific tests in the
phoenix-deployment, maybe we may simply introduce a basic-deployment
module having no dependencies (no spring, no phoenix) and put there the
integration tests. (opinion?)
If we do this then the filepair package can easily be moved to a
function, too.
Once we confined cornerstone/excalibur to functions we have 2 roads to
follow
1) remove also avalon-framework from libraries (not a big priority for me)
2) create alternative functions (having no cornerstone/excalibur
dependency).
Working on this we'll probably have to extract some code from the
functions to libraries so to be able to reuse some of that code and
there will probably be a bit of work in moving down "generic" code
having no dependencies, but we will be able to approach each function as
a separate task.
The protocol functions are probably the first functions to be interested
by #2 and your proposal to extract the protocol code to libraries
perfectly matches this roadmap.
***: the real fact is that we should move management apis/interfaces to
a management-api module and the "impl" classes I'm talking about should
be refactored to be cornerstone/excalibur free (most time they don't
need it, it is only an hack to avoid the dependency injection way) and
in a library.
Maybe we can now move up to library/functions and then move down
later. I don't have issues moving stuff up and down as long as we stay
in a single product.
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] dependencies visualization
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Aug 13, 2008 at 12:37 PM, Stefano Bagnara <ap...@bago.org> wrote:
> I'd like to share a couple of charts I created yesterday to better
> understand the current status.
very cool
thanks :-)
> I created a graph including the dependencies between our modules and with
> external jars.
>
> Here is what yED automatically creates by reducing and creating an automatic
> left to right "tight" directed dependencies tree for
> http://people.apache.org/~bago/server/2008-08-12-server-trunk-modules-full-dependency-tree.gif
>
> THe groups are also automatically created by yEd by using the "Autogrouping"
> "Directed Subtrees" option.
>
> Here is a smaller graph created by closing the groups created previously:
> http://people.apache.org/~bago/server/2008-08-12-server-trunk-modules-full-dependency-tree-closed.gif
>
> I find it cool how an automatic layout created a clear visualization of our
> 3 layers (api, library, function).
>
> I used green for our modules (light for apis, medium for library, dark for
> functions) and light azure for the util modules.
> I then used red for avalon framework, purple and orage for excalibur and
> cornerstone. Blue is for commons-*. Violet is for other james products.
>
> Edges are coloured as the target node, so to easily see what kind of
> dependencies each node has by looking at exit edges colours.
>
> It's not perfect (it does not contain all of our dependencies and classes)
> but I found it interesting and I wanted to share it.
great
> From this graph we can see that once we remove most cornerstone/excalibur
> dependencies by using delegation in avalon-socket-library the only
> cornerstone/excalibur dependencies will be the datasource related ones
> (cornerstone-datasources-api, cornerstone-datasources-impl,
> excalibur-datasource) and the store-api. ATM core-library,
> management-library and avalon-socket-library have direct dependencies on
> this jars. I'd like to confine them to functions as a short term goal.
care to expand?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org