pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Brind <bri...@brindy.org.uk>
Subject Re: Make Pivot JARs OSGi-compliant
Date Wed, 15 Jul 2009 10:06:38 GMT
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.


2009/7/15 Niclas Hedhman <niclas@hedhman.org>

> On Wed, Jul 15, 2009 at 3:52 PM, Christopher Brind<brindy@brindy.org.uk>
> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message