Robert Burrell Donkin ha scritto:
On Wed, Aug 13, 2008 at 12:37 PM, Stefano Bagnara <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
