>> "Don't program to the OSGi api" !!! > > What do you mean by that?
That is the first point I generally make in my OSGi Best Practices talks. Basically it comes down to "use dependency injection". Whether that is DS, blueprint, pico container, ... And it doesn't matter if you are injecting "services", "extensions", "beans", .... In fact the point is that you don't know or care what they are. The example we develop in the OSGi book (http://equinoxosgi.org) ends up with 80 bundles and very few have ANY reference to OSGi packages. This makes it easy to test, easier to write and easier to reuse. Normal programmers should not be referencing OSGi API >> You can start with your "non-osgi" application, launching an embedding >> osgi framework (see core spec) and aggregating the first parts into a >> service/component approach, step by step. > > That was the plan. Put everything into one bundle and start up the > application. If its still running and behaving like it did before start to > carve out small parts into OSGi services. Like Peter suggested. I think Oliver's approach was somewhat different. If I got it right, he is saying leave your non-OSGI thing and run a framework inside it. Carve out parts of the app and have them run in that embedded framework. Basically eat the monolithic wad from the inside out. Mixed opinions on my part. It may avoid/defer some classloading nastiness but it may also artificially introduce some as you cross the OSGi/non-OSGi boundary. My first inclination would be along Peter's lines of wrapping the big chunks in bundles and refactor them. This has worked well for me and my clients in the past. As for the native stuff, you don't have to use a fragment. Fragments are useful if you want to ship for multiple platforms and don't want to ship all platforms to everyone. Other than that, there is no particular value in using them. Jeff _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
