Galileo Podcast Series: Improvements to PDE for OSGi Tooling
|Artist:||James Sugrue - Chris Aniszczyk||Plays:||95|
|Length:||29:41 minutes (8.5 MB)||Downloads:||9780|
|Format:||MP3 Stereo 44kHz 40Kbps (CBR)||Download:||Click to download|
About this podcast
In the first of our series Galileo release podcasts, we meet Chris Aniszczyk to discuss the improvements made to PDE, the Plug-in Development Environment, for OSGi Tooling. Chris also explains the rise of OSGi and the importance of declarative services.
James Sugrue: Could you introduce yourself to the listeners, please?
Chris Aniszczyk: Sure. I guess I'll first talk a little bit about my background at Eclipse. I co-lead the Plug-in Development Environment project at Eclipse, otherwise known as PDE. I do a lot of various other things for Eclipse. For example, I sit on the Board of Directors on the Eclipse Foundation. I'm honored to represent the Eclipse committers there. I also sit on the various councils that make up the Eclipse ecosystem, like the Eclipse Architecture council and the Planning council.
Sugrue: You're pretty active really in the ecosystem itself. Some pretty important roles you have there.
Aniszczyk: Yes, I have been with Eclipse for quite a while, so eventually got put in those roles.
Sugrue: And is PDE the main project that you work in?
Aniszczyk: My main time is spent co-leading PDE. I do dabble in some other projects. Like I have contributed to ECF in the past but I maintain somewhat of a low profile in that project.
Sugrue: So, you are working with EclipseSource at the moment after moving from IBM. So, what does EclipseSource do and what do you do within EclipseSource?
Aniszczyk: Yes, so I left IBM about a year ago to start my own consulting company. One of my colleagues Jeff McAffer pretty much did the same thing. We decided to work together and then, the short history is that later we merged with another company to become EclipseSource.
In essence, if I sort of describe what EclipseSource does, we simply provide services, products and solutions for the Eclipse ecosystem. If you look at the company profile, we have about 30 employees and our expertise is we lead about a little over 10 projects at Eclipse, stuff like PDE, RAP, Equinox. We have people on all those projects.
Sugrue: Before we talk about the OSGi tooling that's been added to the PDE, can you talk a little bit about why is OSGi so important when we are talking about Eclipse?
Aniszczyk: So, if we really look at the history at Eclipse, OSGi is really at the foundation of the Eclipse runtime. It's the essence of what it really means to be a plug-in or a bundle in OSGi terms at Eclipse. It's really hard to write any extension or plug-in at Eclipse without touching some aspect of OSGi. I think it's even more important now that if you notice over the past year, OSGi has kind of hit the main stream.
A lot of people are talking about it, settng up on application servers like GlassFish and WebSphere, so it's pretty important that OSGi is out there.
Sugrue: And so what is the state of play up to now in OSGi tooling, before any of these improvements happened?
Aniszczyk: Eclipse has been tooling OSGi for about five years. If you go back, Eclipse used to have its own plug-in model about five years ago, the Eclipse run time was replaced with OSGi, which was a good decision at that time. So basically, we shifted our efforts from tooling the old runtime to tooling OSGi. So, that's pretty much the story. We've been tooling OSGi for probably over five years at Eclipse and unfortunately, there's been a little misconception out there because Eclipse has its own notion of something called plug-ins, but plug-ins are really OSGi bundles.
So, a lot of people get confused when they see plug-in, but plug-in is just a bundle, right? There's really no difference.
Sugrue: So people should just think of it all as one thing, whether it is a plug-in or a bundle?
Aniszczyk: Yes, it's just a bundle. We have the legacy of having the term plug-in because that's what we used a long time ago, right? So, OSGi wasn't really relevant for us until about five years ago.
Sugrue: I guess in a way, plug-in is a nicer term for it for describing a bundle.
Aniszczyk: Yeah, I'm sure the OSGi guys may have some hesitation for choosing the word "bundle" so in the end it's a unit, a functionality, right.
Sugrue: So, what are the improvements that have been made in the Galileo release?
Aniszczyk: In the Galileo release, I think the biggest focus that PDE had was a few things. So, the biggest focus was around target platform management. In PDE, the fundamental concept when you are developing plug-ins and applications is you work against a target. So, you are developing an application. You work against a set of plug-ins that represent your target platform. So, in the past, the way we work with targets was very weak. You would simply just point to a directory and we would repopulate your platform based on that - just a directory of bundles and not so efficient.
What we did in 3.5 and Galileo is basically defined a file, a description to talk about what a target is. So, basically you could say that a target is composed of these bundles or features from these locations, like a P2 repository.
Then you could use that file to automatically populate your target. So, you can fetch bundles from a P2 repository automatically. You could also share this file with your colleagues. So, if you are working on a team on a project and you want to make sure everyone has the same target that they are working against. All you need is this file.
In the past, there was a big problem of sharing targets with people because there was no consistent way of doing that.
Sugrue: Well, that actually sounds like it would be really, really useful in organizations that are building up based on Eclipse.
Aniszczyk: Yes, it's kind of got the Mavenesque quality where dependencies will just be fetched using P2 and all of a sudden you have an environment where you can do your application development.
The other things that we focused on were OSGi related tooling. We tooled declarative services. Declarative service as a runtime aspect is shipping with Galileo, so it was contributed by Prosyst. Having declarative services is great but without tooling it is hard to use, so PDE decided to tool it.
The other main focus we had was something we called API Tooling and we added a bunch of functionality to that. So, that basically makes it easy to tell whether you introduce any breaking API changes into your plug-in.
So, for example, if you're working on a plug-in and its version 1.0 and you start a new development cycle and you remove a method from like a public API class, that's sort of a breaking change. So, API tooling will inform you that: Oops, you removed a method so you either up your version to 2.0 or don't do that.
Sugrue That sounds good as well. Sounds like they are very important tooling features. Do they exist anywhere else, these type of utilities?
Aniszczyk: As far as I know, there hasn't been much tooling around declarative services in terms of like having editors and graphical type tooling that people are used to. I know at the BND project that Peter Kriens initially started, has some sort of command line stuff to help generate declarative services files. And really in terms of API tooling, I don't think anyone else is really exploring that space. So, I think we are pioneering tooling around API version management, things that are very important once start building large scale OSGi applications like Eclipse.
Sugrue: Well done on taking the initiative there. And could you explain a bit about Declarative Services?
Aniszczyk: Sure. If I was going to simply say what declarative services are - simply a way of interacting with OSGi services. At it's core is a notion of a service component definition. This definition contains information such as the services you provide and need along with some other further metadata like service properties. It's really useful when you are working OSGi services because if you have any experience working with OSGi, doing it programmatically is very cumbersome. Usually it's quite a bit of code to get a service and it's also very error prone once you start working with a lot of OSGi services. So, once things become a little more complex, it becomes quite error prone.
I have seen very little code out there that programmatically works the OSGi service that is actually correct.
Sugrue: I saw at Eclipse that Jeff McAffer did a talk just showing a little bit about declarative services. I think it was Best practices in OSGi. And Declarative Services did really seem like a much better way of doing things. But, is there still a case for taking the ServiceTracker-lots-of-code approach? Is there a case that Declarative Services won't help you?
Aniszczyk: So, I really don't think there is. The recommendation I usually give people, if you're working with OSGi services, use Declarative Services. It's going to save you a lot of heartache in the future, especially with really issues that may come up, especially around synchronization, if you're using sort of the ServiceTracker approach. The only reason I think you could potentially use something like a ServiceTracker is if you're working in a really constrained environment where DS may not be an option. The DS runtime itself is pretty small, but if you're working on embedded devices, sometimes maybe the option of having XML parsers isn't there, so you'll just use ServiceTracker instead of DS. I would say I've run into people that that has actually been the case.
Sugrue: And with Declarative Services, which I've messed around with them briefly, you do need to load up your plug-ins, still, in order to get your service. There's no way of having the plug-in lazily load, is there? Or have I got something wrong?
Aniszczyk: So, basically, OSGi services themselves are tied to the active-life state of a bundle, so in order for your service to be present, your bundle has to be started. But with DS, with the new specification, 1.1 - that's part of the OSGi R4.2 spec - basically, the ability was added that DS can now inspect bundles that are in the starting state. That means their bundle activation policy is lazy. So, basically, if you have a component file and your bundle is lazy, you could still use DS and not have your bundle explicitly started. It could be in the starting state, and things could still work. So, that's how you sort of get the laziness. At least, that's what Eclipse uses for, pretty much in general, all around, is the lazy policy.
Sugrue: Right. I need to go back to my code. Are there any plans to continue these improvements in 3.6?
Aniszczyk: So, now that we've shipped Galileo, we've kind of stepped back a little bit and taken a little break. But, we've started to do some preliminary planning in PDE. And in 3.6, we're really looking at polishing more of the DS tooling. So, the tooling was sort of added late in the cycle. I think 3.5 M5, we started to add it, and we got some feedback. But now, a lot of people are starting to use it, so expect to see a lot more enhancement, kind of like the polish you see all over Eclipse, like refactoring support - you change the name of a component definition, things get updated properly. So, just like little polish items like that, I'd expect.
We're really looking at expanding out API Tools efforts at Eclipse. So, right now, API Tools only looks at sort of the require-bundle level things and versions number for required bundles, because that's mainly what we've used at Eclipse historically. But, we're looking to expand things at the package level. So, that better supports sort of the traditional OSGi people who prefer to do everything with packages.
Also, we're looking at the ability of properly suggesting version ranges. So, one problem we've had at Eclipse for a long time is, say you depend on something, right? You have an option of specifying a version range, right? I depend on this component, and the range is like 3.2 to 4.0. Specifying the lower bound has always been difficult, because you either kind of guess or you really have to poke into things to see what the actual lower bound is. Well, we're looking at API Tools to automatically tell you what that lower bound would be.
Sugrue: That would be good. You have a lot planned for 3.6. And in 3.5, is there any new wizards or anything for PDE tooling? Or is it all on kind of when you're in the project?
Aniszczyk: It's mostly when you're in the projects. I think the new things that people will see is probably the Declarative Services tooling. There are some wizards around there. And the target management is completely new to people. So, basically, people familiar with the target platform preference page, it's been completely revamped. There's new wizards there on how to manage your targets, how to share your targets, and all that stuff.
Sugrue: Just when I was getting used to it. Have you any tips for people who are starting to use OSGi, or people who are thinking about using it, in their applications?
Aniszczyk: It's an interesting question. I've been working on OSGi for quite a while, so I have my own set of biases. I mean, I basically first would recommend, probably, people to get like a book or a resource on the topic. There's a few books coming out on OSGi now. There's a book by Richard Hall. There's the "OSGi in Action" one. I believe Jeff McAffer and other people are writing a book on Equinox OSGi, which I really like. So, I would probably start with that. So there's some really good examples in those books that sort of teach you about the basic OSGi concepts that a lot of people have trouble with: the whole concepts of why modularity is important, breaking up your code into little pieces, working with things that come and go. A lot of people don't have experience with that, so starting with a good solid book resource, I think, is good.
If you're not really into books, there are a lot of templates in PDE. We have a few templates for basic OSGi projects, kind of your "Hello World" type things: "Hello World" OSGi service, "Hello World" Declarative Services. So, those are pretty much at the really basic level.
Sugrue: And what are you looking to most in Galileo, apart from your PDE stuff?
Aniszczyk: Besides actually shipping? I mean, there's a lot of cool projects that are shipping part of Galileo. But in particular, my favorite project is the Eclipse Memory Analyzer project, or MAT, some people call it. MAT. It's really an awesome project if you're really trying to look at the memory consumption of your application. Basically, you take a quick heap dump of your application, and, using MAT, you could immediately potentially memory leaks and other things. It's quite amazing. Having that project out there and people using it and having it used with their own applications should do a lot of good for the world, in my opinion.
Sugrue: And will that come with all distributions of Eclipse?
Aniszczyk: I don't think it actually ships in any of the packages. You're going to have to go to the Galileo repository and actually get it, or you could go to the MAT website and get it. I think, at the MAT website, they also offer a standalone RCP-client version of MAT, so if you just want that instead of having it integrated directly into your Eclipse, if you just want a standalone client, you could have that, too.
Sugrue: Good tip. And you're in the process of writing a book on RCP development at the moment? How's that going for you?
Aniszczyk: It's going pretty well. I mean, we've been working on it for quite a while, on and off. We first started probably about a year ago. We decided to up and write a second edition of the RCP book. Initially, we wanted to focus on 3.4. But, time passed, and if you ask anyone who writes a book, it's quite a daunting process. We eventually decided we're going to hold off a little bit, because there's a lot of new, cool stuff coming in Eclipse 3.5. And in particular, P2 was going to be fleshed out a little bit more. Some new features in data binding were coming along. So, we decided to wait and focus the book on Eclipse 3.5. So, we plan to pretty much have the book out later this fall, so we're in the process of kind of wrapping things up.
Sugrue: It's a huge topic to cover, RCP development, so I can imagine how long it's taken you. Is there going to be a whole chapter on P2?
Aniszczyk: Yeah, there'll be a full chapter on P2 and data binding. If you actually remember the first edition of the book, there was an example called Hyperbola. It was pretty much a chat client. And so we've done a couple things. One thing we did is, before, we just had a simple XMPP client dependency that we used, but we decided to rip that out and actually use ECF under the covers. So, we expose people a little bit to ECF - not much, but a bit - because I think it makes more sense. It kind of shows the power of reusing various projects within the Eclipse ecosystem. And in terms of P2, we'll have a chapter on actually adding some P2 support to Hyperbola, so the whole updating process and all that fun stuff. And there actually will be another chapter that sort of goes in-depth on P2, in general, kind of explains the concepts and all that stuff a little bit more in-depth than just, "Here's some code, and here's how to add P2 to an RCP application." Something a little bit more in-depth.
Sugrue: I'll be looking forward to that. P2 is still one of those mysteries that hangs around Eclipse for me. Even though I did get pointed to a good wiki page on that by Jeff McAffer there, which seems to have all the information I need. It's just a matter of reading it.
Aniszczyk: Yeah. When more people start using it, more documentation will pop up. We had the same problem, a long time ago, with update, right? A lot of people wanted to add update functionality to their RCP applications. And it's just a matter of time until the documentation is written and people start realizing how to do it.
Sugrue: Have you noticed any changes in the Eclipse ecosystem over the last year?
Aniszczyk: I guess I have a little unique perspective on that because, if I put my developer hat on, sure, I see a lot of changes, and if I sort of put my board-of-director, foundation type hat, I see a lot of changes, too. So, if I first go with sort of the board-of-director hat and business-world type hat, I see Eclipse making a lot of trends in sort of industry verticals. So, I think it was almost two years ago, the Eclipse Foundation decided to form some things called industry working groups. So, these are pretty much little groups that allow people from the same industry to sort of come together and build on Eclipse technology and, basically, exchange ideas, a forum for exchange of ideas on how to sort of work with Eclipse.
So you look at today, and the industry working groups that we have today, I think, center around mobile. Actually, one deliverable of that working group, what they did is they delivered a package called Pulsar. So, as part of the Eclipse Galileo release, one of the new packages that is available is called Pulsar, and that's basically a slew of mobile tooling, useful for people, that build on top of Eclipse. So, if you need mobile tooling, you will go to Pulsar.
Also, there's an Automotive Industry Working Group, I think, that's being formed, and there's a new one based on SOA.
Basically, the trend I see is Eclipse extending itself through a lot of these sort of industry verticals that they themselves are already using Eclipse within their own companies, but they haven't really found a way to work together to sort of, maybe, "All right. All of us are working on Eclipse, but do we have to hide everything from each other? Can't we just build on some common pieces within our vertical?" Sort of the whole process that goes along with building a common platform.
Sugrue: It's a good idea to bring in these type of working groups, definitely. And it really strengthens Eclipse's community.
Aniszczyk: Yeah, definitely. I mean, people see the value of having a common platform to build on. We saw this a long time ago. It only makes sense that other industries are finally saying, "It doesn't make sense to pay for everything ourselves. Why can't we share some of the costs on common components that don't necessarily really provide any value for just us holding it internally?"
Sugrue: So that's what we've heard from "Chris from the board of directors". And then, what about Chris, the developer?
Aniszczyk: Chris, the developer, sees a trend that Eclipse has done really well in the tooling space. So, pretty much anywhere you go, you see anyone that does tooling for a runtime is pretty much doing it on top of Eclipse. You look at, let's say Android. Android's tooling is all on Eclipse. Salesforce. eBay has tooling. So, I think we've done really well in the tooling space. The place I see us going is we're going to have a bigger runtime presence in the future. Our new top-level project at Eclipse is called Eclipse RT, and so we basically have a lot of runtime-y projects there at Eclipse. So, for example, ECF is there. Equinox actually moved out of the platform, top-level Eclipse project, to the Eclipse RT project. You see Jetty there. You see EclipseLink there.
So I expect to see Eclipse grow a lot more in sort of the runtime space, sort of in the area that Apache has kind of known to sort of dabble with for the longest time. So, I expect to see more runtime-esque type things come out of Eclipse.
Sugrue: was really interesting to see Jetty coming over to the runtime project, actually.
Aniszczyk: Yeah. They moved to Eclipse for a good reason, in my opinion.
Sugrue: What are your thoughts on the future of Eclipse?
Aniszczyk: So that's a good question. On the point of the whole runtime thing, I see Eclipse expanding in sort of the runtime space, definitely with projects like Jetty coming. And I also see more projects coming at Eclipse that really want to do serious open-source development. Eclipse is known for producing high-quality software. We have a rigid development process that really works well for us. We have a fantastic legal process that goes along with that. So, stuff like this makes the open-source software you develop very attractive to commercial entities, because it's been legally cleared, it's gone through a nice development process, and also, just in general, it produces high-quality stuff that anyone could use. So, I expect people sort of coming to Eclipse to do that type of work.
Even the work that Eclipse has done, like the foundation with its development process, other people have modeled their foundations on that process. So, if you look at the Symbian Foundation that was formed recently, they use the same license that Eclipse does, and they've pretty much created this foundation based on a lot of the principles that the Eclipse Foundation operates on.
Sugrue: And what are the most interesting uses of Eclipse that you've seen over all your time that you've been involved?
Aniszczyk: Oh, that's an interesting question. I mean, I've seen Eclipse pretty much used everywhere, Whether it's NASA using it, on the Swiss railway, oil rigs using Eclipse technology. Let's see. If I was going to pick the most interesting one, here's one cool one. So, there's a small company out there, Band XI, that they sort of focus on like the embedded Eclipse, embedded OSGi space. And one of the things they did was they used Eclipse technology to sort of build a threat-detection system.
So, basically, what this means is, say, for example, you're attending a large sporting event or like a music event, and they have these sensors all around this event, in various places, to detect types of threats. For example, if there's, I don't know, say, like a gas or something bad happens, whatever this sensor could detect, it'll feed it to a master control center. So, basically, they built this awesome threat-detection system using the power of Eclipse and OSGi. I thought that was kind of cool. At least, I've never seen anything like it.
Sugrue: Either in Eclipse or outside of Eclipse. It sounds pretty innovative, really.
Aniszczyk: Yeah, definitely. The other interesting use case that I like to bring up is the NASA folks, because, initially, they started to use Eclipse as a sort of RCP type of platform to build their applications. And then, eventually, other teams started to look at, "Oh, we like what these guys did with RCP for the NASA Mars mission. We have our own mission coming up, and we want to reuse some of the scientific visualization pieces you did with the Mars mission in our mission." So, basically, what happened there was [laughs] one team developed a cool piece of technology that other teams wanted to use. So NASA, in the end, started to build like a common platform piece that the other teams in NASA would use for their own various missions. It's just interesting to see that evolution of just a simple application that's useful for one people turning into a common platform that's used all over NASA for various missions. It just fascinates me how that stuff works.
Sugrue: It seems, once you start using Eclipse in any small way, you find other uses for it, and you just can't shake it. It's just like an addiction or something.
Aniszczyk: Yeah. Everything's a plug-in or a bundle, right? You develop a plug-in for visualizing, I don't know, scientific data, right? And someone else will find that useful, and since it's already a plug-in, it may not cost too much work to actually maybe re-factor it and to have it used by someone else. It's just the beauty of how it works. Once you start thinking about bits of functionality, bits of plug-ins, it enables reuse. That's the story we've always told people in software, that we could create these cool, reusable components. And people are starting to do that.
Sugrue: It's all good. Thanks a million for your time. And, yeah, really looking forward to getting the Galileo release and trying out all of your PDE tooling stuff.
Aniszczyk: No problem. Feel free to file bugs and enhancements. That's the best way to talk to us. We thrive based off of our user community.