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
