On Nov 30, 2007 7:52 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: > > On Nov 25, 2007 6:34 PM, Robert Burrell Donkin > > <[EMAIL PROTECTED]> wrote: > >> On Nov 25, 2007 6:06 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > >>> Robert Burrell Donkin ha scritto: > > > > <snip> > > > >>>> 5 unsure about the granularity of avalon-user-function and > >>>> jdbc-user-function. lots of small components allows precision but > >>>> perhaps might be better to aggregate into large units including all > >>>> backend implementation of the same type. for example, > >>>> avalon-backend-function including all the avalon* implementations > >>>> (AvalonRepository and so on). > >>>> > >>>> opinions? > >>> IMO it's better to aggregate jdbc-user-function to avalon-user-function. > >> why? > > > > i've adopted stefano's suggestion but a longer explanation would be > > appreciated > > > > - robert > > My main motivation was about having a limited number of modules.
ok - so this is where the arguments about component granularity kick off ;-) > IMHO we should keep the number of modules under the 20, otherwise it > will become worse than the old all-in-one structure. setting an arbitrary number defeats the whole purpose of the process :-) separating JAMES out into logical components reveals and expresses the coupling within the system. a finely grained component structure will make dependencies more obvious. it should be possible to assemble smaller, lighter applications from the JAMES components. many users seem to want this. ATM it's not really possible to do this safely. it should be possible to retain a much more diverse, interesting and useful codebase if a standard, lightweight JAMES can be cut by removing components. users wanting optional or non-standard modules would need to build from source. > IMHO having modules with very few classes in there does not make too > much sense: I prefer to use java packages for that. the packaging in JAMES is very coursely grained and cuts across functional devisions. for example, APIs for every sort of service are packaged in org.apache.james.services and so if you want POP3 then you have to take IMAP. i would like to fix the packaging but i understand why people want to preserve config files. separating the codebase into a finely grained component structure is a reasonable substitute and can be done immediately. this process will inevitably go too far. (IMAP has too many modules.) but this is an exercise in comprehension. once the code has been broken down and the dependencies fixed then we can reaggregate. > IMHO too many modules is an anti pattern. define too many without selecting an arbitrary numeric value :-) i think that JAMES needs to move towards finely grained COP ATM. this will allow the dependencies to be fixed in an evolutionary manner. IMHO the future for trunk should be pruned releases. experimental and innovative code should be allowed in trunk without having to convince people of it's value a priori. first, the APIs are finalised on trunk. (hence API modules.) before a release, immature modules and general cruft would be pruned on the release branch. these modules which didn't make the cut would still be available by compilation of a tag. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
