On Thu, Aug 14, 2008 at 2:09 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > 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.
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
