I too believe that we are agreeing. Before everyone gets bent out of shape about classifying programmers (not my goal), my point is that IMHO most Java programmers in the wild today have no need to reference an OSGi API package. They might do well to use a *pattern* that OSGi also uses but the "extender" and "white board" patterns are not exclusively OSGi and do not require OSGi.
Don't get me wrong, I like all this stuff and think it very valuable. However, the adoption challenge that OSGi faces is increased if people think they have to swallow the whole pill to see the shining path. Philipp knows a lot about OSGi so understands but others looking to migrate may not. Many folks have derived huge benefit simply from being modular. Not a single service or dynamic behaviour in sight. The message is API, high cohesion, low coupling, ... as software engineering goals. OSGi supplies a number of mechanisms for achieving these. I think we should do more to promote the incremental OSGi adoption by doing a better job of hiding it. As for testing, PDE (headless or GUI) has enabled running JUnit tests with and without OSGi for years. But running a test in OSGi still requires more work than running one stand alone with injected mocked up objects. Referencing OSGi API in general requires OSGi to be running. That in turn requires all manner of other bundles, configuration, ... I spent years doing that and found it hard and frustrating. Switching to DI, EasyMock et al and writing code that did not depend on OSGi API or require a running framework made testing much easier. Jeff On 2010-11-11, at 8:32 AM, Peter Kriens wrote: > Jeff, though I do believe we agree in general I do not see the concept of a > "normal" programmer. A good module (function -> module -> class -> package -> > bundle) is highly cohesive, meaning it focuses on a single problem domain. > If you're problem domain happens to be simplifying the life of other > programmers the OSGi API is often right at the heart of that domain because > patterns like the extender and white board do simplify solutions in this > domain. However, if you write a tax return application, OSGi has no place in > your code. > > I therefore do not think we can make the distinction between "normal > programmers" and "special programmers?" that easy. There are undoubtedly > programmers that will never have to touch OSGi API but imho it is often too > much of a benefit to utilize one of the OSGi patterns, turning "normal > programmers" into middleware programmers. They key thing is not to minimize > the domains in one component. > > Last thing, with bnd(tools) there is no difference in testing anymore between > straight JUnit and JUnit that runs inside a framework, both inside Eclipse > and outside Eclipse with ant or some other build tool. > > Kind regards, > > Peter Kriens > > > On 10 nov 2010, at 16:05, Jeff McAffer wrote: > >> >>>> "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 >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
