On Wed, Dec 17, 2008 at 11:45 PM, Richard S. Hall <[email protected]> wrote: > For the most part, I believe what you describe is possible with what OSGi > provides. Clearly, a lot of legacy code makes this difficult, but that is > not the fault of OSGi (nor the legacy code, since it was created pre-OSGi). > > The real issue is not where API packages reside, rather it is that tools > like Hudson do not understand the dependency model of bundles.
1. Yes, it is in theory possible, provided that; a. The container doesn't have obscure bugs. b. The programmer manages to clean up the mess in stop(). c. That the stuff "cleaned up" really do what it claims. 2. Yes, but we have a lot of programmer's who have not been 'fed the red pill' and don't even know how deep the rat hole goes, and continue with current practices. So, from my PoV, fixing the tool chain is only a fraction of the overall problem. Yes, it fixes the build part of OSGi/Modularity conscious individuals, but that doesn't mean it is a 'solved'. As for containers properly working in endless update/refresh cycles -> I only know that 2 years ago, even one of the simplest cases didn't work reliably on Equinox, and I therefor doubt that the more complex scenarios that are possible in OSGi actually works reliably today. Problem being that it is extremely hard to test (TCK is far too weak in this area) and diagnose, so I am not surprised... It is an excellent tool for development, but I don't dare to recommend it (no restarts) today for any mission critical applications. Hopefully this improves over time. Cheers Niclas _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
