On Wed, Jul 15, 2009 at 3:52 PM, Christopher Brind<[email protected]> wrote: > Before jumping in and solving our class loading problem I would say it is > more important to establish what we're trying to achieve by this exercise.
Fair enough... > Is the goal essentially to be able to start a pivot application from within > an osgi container and then allow the application and ui to be extended using > the osgi mechanism? > > Or did you have something else in mind? I don't have a 'use-case' in mind, but I have been around the block a dozen times of adapting something for OSGi (in various forms) to know where the problems will be, and common approaches to solve them. For Pivot, I would recommend the same approach as we have in Qi4j, i.e. "OSGi-friendly but not OSGi-dependent". That basically means that the Jar files are OSGi bundles that will work both in OSGi and in a OSGi-free environment. It means that OSGi requirements are met in terms of classloading, and in Qi4j it means that OSGi services can be 'imported' if the extension is installed (not done yet). Exactly how far down the 'friendliness'-path you want to walk is not something needed to be decided upfront. It can be a slow progress, driven by actual use-cases. > How would this work in the applet environment, if at all? Perhaps poorly. The applet would start an OSGi framework, which in turn would load the bundles needed, possibly lazily. > That is, I am trying to understand the use case you are thinking of, though > I am starting to guess that you are talking from the desktop application > point of view? As I said, I don't have the strong use-case yet. My messing around with Pivot so far is rudimentary at best, and although I have a long-term plan for using it, that plan may or may not include OSGi. It is something not decided yet. In fact, I have not even decided whether it will be applet, jws or desktop app, although jws is a personal favorite of mine. > How do you see the deployment of an osgi based pivot application working > and what are the deployment scenarios? I love plugin concepts, and since I first wrote my own plugin system back in 1999 or so, I am equally concerned that a good plugin system can unload/reload plugins on the fly. OSGi R4 can make this a reality, much easier than fooling around with Java 2 classloader model. But it comes at a price of how you should deal with classloading. And since most systems that has some form of classloading mechanism (Pivot incl) assumes that the world == Java 2 classloader model, you are set for problems. Eclipse for instance, is since 3.0 based on OSGi, but has been unable to make the reloadable plugins a reality, since too much code are not following the classloader constraints set in OSGi. I doubt that they will ever try to solve it properly. For Pivot users, who want to build RCP-like applications, it would be nice if Pivot was "OSGi-friendly" and the frameworks built on top could be fully reloadable. I think the overall effort from Pivot is quite minimal, and will largely be a) a single classloading pattern and b) testing effort to ensure that it works in each release. > With regards to bnd, yes it is a good tool, but i think it could be overkill > here. Once we establish our goals someone with osgi experience can simply > write the headers in to manifest file to be referenced at build time by the > jar ant task rather than introducing a new and potentially complex step in > to the build. I disagree. To create and maintain the manifest is actually much, much harder than you may initially think. And in comparison, the BND descriptor is fairly easy to maintain and for Ant I think it is one antlib and one target that you will need to add. > Since most of us are using Eclipse that is actually quite > easy using pde tools and will probably only need doing once, or very rarely, > so shouldn't affect those using some other ide. The PDE toolchain is of poor quality. In fact, most leading OSGi developers who are also Eclipse users, never use the PDE due to its limitations, bugs and different approach than what is expected. In fact, it is so bad that I use Idea even when developing Eclipse plugins... And it will be a manual process, and with not enough usage in the dev team, likely to be error-prone during releases. by comparison, the BND tool is automated, relatively fast and requires that all classes are marked explicitly, just to ensure that one didn't just "forgot". So, releases is just a matter of looking out for BND warnings. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug
