If you’re interested in the topic of having Equinox Declarative Services ship with the Eclipse SDK, check out this mail thread on eclipse-dev. There’s also a bug open you can follow.
It would be great to hear from the greater Eclipse community about this topic.
For those that are curious, Equinox is planning a move to Foundation 1.1 in the 3.5 timeframe… if you have any problems with this, speak now or forever hold your peace 😉
For those who don’t like all this talk about tiny execution environments, check out BJ Hargrave’s EclipseCon submission about OSGi Framework 2.0… J2SE-1.5 at the framework level… sounds fun!
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.
So it looks like OSGi isn’t a secret anymore… it continues to be adopted by the JEE crowd according to a new press release. The only problem with that press release is that it’s somewhat of a farce. I know of only a couple companies that are truly pushing OSGi as the actual application model… not the decrepit JEE stack of technologies like EJBs and friends.
Sure, it’s nice to say that you’re taking advantage of OSGi as the runtime for your application server, but how about for the application model? Once we have bundles running on desktops, servers and devices… things start to become very interesting as this will be the first time I think the industry has one application model across target environments (desktop, server, device).
Maybe all my agnst against JEE is coming out today 🙂
What do you think?
I recently blogged about how to deal with third party dependencies in an OSGi-based environment and a thought came across my mind about putting ourselves in a crappy situation. What do I mean? Well, let me illustrate with a simple example using the Apache Commons Discovery library. In the Spring Repository we see this:
...
Bundle-SymbolicName: com.springsource.org.apache.commons.discovery
Import-Package: org.apache.commons.logging;version="[1.1.1, 2.0.0)"
...
In the Eclipse Orbit repository:
...
Bundle-SymbolicName: org.apache.commons.discovery
Require-Bundle: org.apache.commons.logging;bundle-version="[1.0.4,2.0.0)", org.junit;bundle-version="[3.8.0,4.0.0)";resolution:=optional
...
I wonder what we’ll see when Apache decides to start offering bundles as a download option… the point here is that we are in a precarious position with third party libraries. Each bundle repository will have its own format when it comes to things… they may conflict or they may not. For example, the current example conflicts because of the choice of using Require-Bundle versus Import-Package as the way to express dependency information. The problem could be fixed if Orbit switched to using Import-Package but this still doesn’t help people who are using Require-Bundle as a client of these libraries.
It seems we may need some set of best practices that bundle repositories follow that ensure bundles from each repository are interoperable. What are people’s thoughts on this topic? Have you been bitten with interoperability issues by using bundles from different repositories? I only see this problem becoming more annoying as more people start adopting OSGi.
An early draft of the OSGi 4.2 spec is out. Learn about:
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.
For those of you who don’t pay attention to mailing lists closely… there’s been a request for feedback on standardizing eRCP in OSGi. Yes you read that right, there are people wanting to standardize eRCP in OSGi to help with adoption. There are some large backers for this proposal… Sprint, ProSyst, Nokia, and IBM.
What are my thoughts? Well, besides the quirks of reverse-specing something… it seems like a good idea. However, I’m still a bit uneasy with where the control lies… does this specification imply that the OSGi community gets to dictate what is in eRCP from now on? What impact does this have on the RCP stack controlled by the Eclipse community? Does the eRCP project in Eclipse become the reference implementation, similar to how Equinox is the reference implementation for OSGi?
Cool stuff… it’s amazing to see the excitement around OSGi and eRCP these days!
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 🙂
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?
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.