> - util/NodeWriter.java > - util/XMLApplicationReader.java > - util/XMLApplicationWriter.java Hi I am in favour of moving as much code as possible out of the core. But what are the prerequisites for such moves. I think one of the most important is that dependencies should only go one way. If the mmbase-core package requires the mmbase-util module and vice versa you might as well not split them. taglib is a good example of code that is separated from the core (taglibs use the core and the core doesn't use taglibs). An other "rule" might be that the module must only do 1 thing well, that's easier to implement document and sell :)
For the email module this is not so easy because the email module performs different tasks. It has become to specific and you have to take the whole or nothing because the inner dependencies of the different components , the builders, the object model (related groups / people) and the mail delivery. As Michiel said you still might want to be able to send an email from the core using the java interface. I for instance would like to send the email using the "old" sendmail interface since I can automatically download javamail.jar Now suppose we split the mail delivery from the email application. That is possible / good because of rule nr 1 (delivery does/should not depend on the email builder or an object model). what dependencies have we then created mail-delivery depends on javamail (and mmbase because it's a module) mail-groupware depends on mmbase and mail-delivery that sounds fair to me. And now the problem. what if we want to send email from the core? In that case core will depend on mail-delivery and this is a problem. are you still there?, read on :) I can think of 2 solutions 1- make the dependency runtime We cloud do the using the functions framework 2- split the mail-delivery interface from the mail-delivery implementations mmbase-core depends on mail-delivery-interface mail-delivery-javamail depends on mmbase-core and mail-delivery and javamail mail-delivery-dumb depends on mmbase-core and mail-delivery 3- combine 1 and 2 both can be helpfull. And I think the same should apply to images -image object model -image convert interface -image-convert-imagemagic -image-convert-jmagic -image-convert-jai_1.2 -image-convert-jai_1.3 The big advantage following the "rule" is that at the end it's easier to understand what a module does and what it's external dependencies are. This would probably require us to start using a real build tool. thanks for reading this far
