work. life. open source. diatribes.

Posts Tagged with “equinox”

How exciting to finally have the Equinox and OSGi book done (see the book review from DZone). In the Eclipse community, many people complain about the lack of documentation and reference material, well that should be less of a problem given the book and excellent Toast example.

I may be a bit biased (see the kind words about me in the Acknowledgments section of the book), but I believe this is the most comprehensive book on OSGi out there. The authors have many years of practical OSGi experience, from the days to when OSGi wasn’t cool yet (SMF) to when it became the basis of Eclipse. On top of that, I think the best thing that comes out of this book is the open sourced Toast example. Expect to see a lot us within the Eclipse community use this example when we talk about OSGi, Equinox and EclipseRT.

Share this:

Ed Merks recently blogged about the Eclipse members meeting. My favorite take way from this meeting was that SAP chose OSGi (Equinox) as their application platform. On top of that, SAP is going to contribute to the Equinox project to make sure that it is “enterprise ready.”

I was pretty sure Equinox was “enterprise ready” already, but I learned that “enterprise ready” in SAP terms is meaning to support something like 50,000 bundles running… sounds like fun! It was also very encouraging to see SAP adopt open-source technology where it makes sense and even commit resources to the open-source projects that are important to them. The move from simply a consumer to a producer of open-source technology is a huge one. For large companies like SAP, this isn’t always easy due to corporate culture.

It was also interesting to see that SAP was very methodical in their choice of OSGi framework. During the members meeting, they showed their test results pitting the various frameworks against each other:

It’s cool to see Equinox come on top most of the time. I’m sure with SAP’s involvement in the future, Equinox will shine even more.

It looks like there’s a lot of cool things going into 4.2… especially things like Distributed OSGi which can have a lot of downstream ramifications on people who use OSGi and want to use it in a distributed fashion.

Share this:

What do people think about internal extension points? Currently, there is no concept about “internal” extension points in Eclipse besides using the convention of having “internal” (ie., internalTweaklets) in the extension point name along with some terse documentation. I know there are also products that don’t ship extension point schemas (.exsd) to prevent their users from extending schemas they don’t want. This is kind of funny because Eclipse is still aware of the extension point it just can’t help the user extend it… since there’s no schema… in essence… the extension point is being hidden… yet it is still there:

I think we can do better than this and try to mimick the concept we have with internal packages and x-friends. For example, imagine an extension point you wanted to define to be used just but your plug-ins for now… it’s useful for you internally but not ready to open to the public yet. In PDE, we could allow you to define an extension point as internal and maybe give it some “friends” that wouldn’t be flagged as discouraged access to the extension point.

What does the community think? Is this something valuable for people?

Share this:

Ian Skerrett must be doing a lot of marketeering today… I’ve been seeing a couple of press releases go through my inbox. Prosyst officially announced some of its recent graduated contributions to Equinox:

This is good news because the old Declarative Services implementation in Equinox sucked due to concurrency issues and Equinox didn’t have any of the other mentioned implementations. It’s good to see more services out there for people to take advantage of… especially when they are in the OSGi specifications.

With that said, anyone want to contribute Declarative Services tooling to PDE? New contributors don’t be scared… I have room for you in the PDE Incubator 🙂

Share this:

In PDE, we’re working on adding OSGi Services information to the Plug-in Registry view… the question came up on how these things should be visualized. It turns out that creating icons for OSGi services is a painful task. This was our initial stab at it:

Not so bad eh? Well, when talking to Equinox Framework extradonaire, Tom Watson, he was a bit confused by the icons. He pointed me to a picture that Peter Kriens uses to describe OSGi services apparently:

That’s cute… I can see that Peter was trying to describe that only one bundle can register a specific service (pointy side of triangle) and multiple bundles can bind to it (flat side of the triangle). However, this doesn’t really help me in creating an icon that normal people would understand… also… why a triangle? So I tried to hack something up quickly in a budget paint program:

Ok, I kept the triangle… hypothetically put an ‘S’ on it to represent service… than I put arrows on the top and bottom of the triangle to represent “importing” and “exporting” services. Nope, I’m not satisfied with this crap either. Actually, when I think about it… visualizing services is as confusing as driving in Boston:

How does everyone out there picture OSGi services in their heads?

Share this:

Do you recall seeing all those access restriction warnings in your workspace because you’re using some internal API from another plug-in? Well, those can come back and bite you if your plug-in is running an in environment where osgi.resolverMode=strict is turned on. What is ‘strict mode’ mean in this context? It basically means that Equinox’s resolver will throw ClassNotFoundException’s when it comes across a class that is in a package marked internal.

There was an issue recently where the RCP stack had trouble running in strict mode. There were a few naughty RCP-related extensions that were referencing internal classes in other RCP plug-ins. These extensions are frustratingly hard to find if there’s no tooling. For example, when launching the RCP ‘Hello World’ example in strict mode, you come across this exception:

You think to your self, well pffft, I can fix that, I’ll just x-friend that package to my plug-in and be done with:

Then you go to launch the RCP ‘Hello World’ example and you get this frustrating exception again:

This is when the game of finding the offenders doesn’t become fun anymore. Actually, the feeling is very similar to when that stupid dog was laughing at you in Duck Hunt because you couldn’t shoot all the ducks:

However, never fear, PDE completed an enhancement that will make it easier for you to find these offenders:

The solution to this problem is to use x-friends or as a better best practice, don’t refer to internal classes outside your plug-in in your extensions as this is brittle.

Happy hunting.

Share this:

There’s been a lot of hustle and bustle for the latest Eclipse I-build. The p2 guys are pushing hard to get things in and the API Tools camp is making their debut. From the PDE UI camp, I was on an icon conquest today with improving icons in the schema editor:

It’s funny that I agonize over things like icons when probably only a few people in the Eclipse community really care about pushing pixels. In the end, I lost my battle with overlays so another redesign of the schema editor icons will happen in the future to make them more overlay friendly:

I also had fun trying to come up with icons representing OSGi services but I’m going to save that rant for tomorrow.

Another item coming from PDE is a filterable launch configuration:

This is incredibly useful if you want to filter for a set of plug-ins and either enable or disable them. For example, say you wanted no org.apache* plug-ins in your launch config, simply filter for them and click ‘Deselect All’ (it’s filter-sensitive now). No more going through and checking things individually! Everyone can thank Ian Bull for his persistence in getting this enhancement in.

The other thing I’m looking forward to in the upcoming I-build is improved colored label support. Look for PDE to adopt this in things like the ‘Open Plug-in Artifact’ dialog and other places that make sense. If you’re interested in test driving this functionality, look for a class called StyledCellLabelProvider in the 3.4M6 release.

Oh, and JDT Core released some crazy changes to support external class folders. I plan on looking at this support in depth after my vacation to see if we can close an old outstanding issue in PDE.