6. “Google chose jetty for App
engine”
Jetty is designed to be
at Jetty pluggable and
fe atures th extensible, so Google
The 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
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.