When best practices in different domains clash there’s no an easy solution: Build systems usually recommend a concrete version for the dependencies rather than range. JEE heavily use META-INF/services concepts which implies that this package is accessible. Optional packages are often declared as optional but no extra care is taken in the source to handle the case when the package is not available Split packages across third party jars are common case and usually refactoring is not an option so sometimes require-bundle is preferable. Guarantee start sequence without services could be tricky and start levels could help as workaround. Drawbacks of that approach (mostly on system update) could be found in every article on OSGi best practices. No silver bullet (yet) just list of open questions which to be considered from multiple perspectives
A modularized JavaEE stack exists. Clears the way for owners of standard monolithic JavaEE apps to start modularizing bit by bit. Experience and Virgo users tell us that once you modularize your app you don’t want to go back to a monolithic approach.
Because everything is so modular and the components we used are relatively loosely coupled we were able to assemble a minimal set of components that satisfy our goal of EE support.
Our goal is to have the Virgo Nano-EE distribution part of the Eclipse Juno release train. It is scheduled for release on June 27th.
A path to modularity with Eclipse Virgo
A path to modularity with Eclipse VirgoBorislav KapukaranovKatya TodorovaMarch, 2012 Flickr: AbiKhairulAizad^^
“Google chose jetty for App engine” Jetty is designed to be at Jetty pluggable and fe atures th extensible, so GoogleThe key osen for were was ch ility.” have been able to size and flexib customize it to a high degree. http://www.infoq.com/news/2009/08/google-chose-jetty