Hi Asankha, I really like your approach here. Thanks for giving the users the chance to express their view and influence the system.
While having a modular system also has some drawbacks - some features tend to be missing and existing modules are possibly never discovered by end users - the installation/deployment gets more complex (increased effort) - issue handling becomes more difficult (users should provide information about additional "modules" they are using if they report issues, as the set of JARs in the classpath can have a great influence on the overall system) I'm a big fan of modular systems. You can decide what you really need and also don't have to bother with issues in modules you don't use. The overall complexity and the number of interdependencies decreases. So, enough general words, here is my personal opinion about the modules (of course influenced by our usage scenarios). ;-) In-memory registry remove (but more or less neutral) acegi support jars remove (a stronger -1), as I would like to get rid of those dependent JARs (could that also fix the TLD-issue?) smooks mediator remove (not to sure about this one, no strong opinion) AMQP transport remove (may change my opinion when this is stable) FIX transport remove (also here a stronger -1, special domain) Regards, Eric _______________________________________________ Esb-java-dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
