Hi Niclas, Just to be clear - I wasn't advocating using the PDE toolchain, I was talking about using the manifest editor only but concur with your comments about Bnd... and everything else. :)
I've not used Bnd because I work in Eclipse and don't like to replicate the meta information in multiple places. Eclipse's approach to bundle development is to store the meta information in a manifest file - which kind of makes sense to me! So I can't see the pointing in maintaining that meta information in a format for Bnd as well. But I suppose if we're wanting to remain IDE agnostic then storing that meta information in a format that can be used by Bnd is acceptable too. Cheers, Chris 2009/7/15 Niclas Hedhman <[email protected]> > 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 >
