Posts tagged ‘OSGi’

R-OSGi and Distributed OSGi: differences and similarities


ECF Eclipse Communication Framework is a framework for supporting the development of distributed Eclipse-based tools and applications. It can be used to create other plugins, tools, or full Eclipse RCP applications that require asynchronous point-to-point or publish-and-subscribe messaging.

Bookmark and Share


Continue Reading 4 September, 2008 at 15:51 2 comments

Equinox Aspect: Example from Martin Lippert

Equinox Aspects imageMartin Lippert is a senior consultant and coach at akquinet it-agile GmbH. His main work and research focuses on Agile Software Development, Refactoring, Eclipse-Technology, OSGi, Spring and Aspect-Oriented Programming.

Martin posts, in your blog, a Code Examples from “Aspect Weaving for OSGi” Talk.
The code example is divided in:

Bookmark and Share

Continue Reading 19 July, 2008 at 10:45 Leave a comment

Neil Bartlett meet Michael Coté (RedMonk): e4, Equinox, OSGi and Android

MIchael Cotè an industry analyst with RedMonk interview Neil Barlett on e4, Equinox, OSGi and Android.

Neil Bartlett is a good, maybe but certainly an expert, of OSGi. I have learn alot throught Neil’s Blog; Getting started with OSGi and OSGi Book.

After letting it rest way to long, I finally got around to editing and publishing this short video with Neil Bartlett
from EclipseCon 2008. As the title implies, we talk about the next major version of Eclipse, “e4,” get into a discussion about the Equinox, and wrap up talking about Neil and other’s work on getting OSGi running on Android.

Bookmark and Share

Continue Reading 18 July, 2008 at 13:34 Leave a comment

iPOJO library: Declarative Services alternative

IPOJO logoiPOJO aims to simplify service-oriented programming on OSGi frameworks; the name iPOJO is an abbreviation for injected POJO. iPOJO provides a new way to develop OSGi service components with the main goal being to simplify service component implementation by transparently managing the dynamics of the environment as well as other non-functional requirements. The iPOJO framework allows developers to more clearly separate functional code (i.e., the POJO) from the non-functional code (i.e., dependecy management, service provision, configuration, etc.). iPOJO combines the functional and non-functional aspects at run time. To achieve this, iPOJO provides a simple and extensible service component model based on POJOs.

iPOJO strength points are :

  • components are developed as POJO
  • the component model is extensible, you can easily add non-functional properties
  • the standard component model manages service providing, service dependencies, dynamic reconfiguration …
  • iPOJO manage the component lifecycle and the environment dynamics

A component is implemented in Java in a “POJO” class. This class does not have any links on OSGi. All requirements, as service dependencies, will be injected at runtime when needed.

Bookmark and Share

Continue Reading 2 July, 2008 at 21:33 Leave a comment

OSGi and AspectJ into Equinox Aspects

equinox-aspects-In software engineering, the programming paradigms of aspect-oriented programming (AOP), and aspect-oriented software development (AOSD) attempt to aid programmers in the separation of concerns, specifically cross-cutting concerns, as an advance in modularization. AOP does so using primarily language changes, while AOSD uses a combination of language, environment, and method.

Separation of concerns entails breaking down a program into distinct parts that overlap in functionality as little as possible. All programming methodologies—including procedural programming and object-oriented programming—support some separation and encapsulation of concerns (or any area of interest or focus) into single entities. For example, procedures, packages, classes, and methods all help programmers encapsulate concerns into single entities. But some concerns defy these forms of encapsulation. Software engineers call these crosscutting concerns, because they “cut” across multiple modules in a program.

Bookmark and Share

Continue Reading 28 June, 2008 at 19:49 4 comments

Pros and Cons of Plugin Systems

A plug-in (plugin, addin, add-in, addon, add-on or snap-in; but see extension) is a computer program that interacts with a host application (a web browser or an email client, for example) to provide a certain, usually very specific, function “on demand”. Applications support plugins for many reasons. Some of the main reasons include: enabling third-party developers to create capabilities to extend an application, to support features yet unforeseen, to reduce the size of an application, and to separate source code from an application because of incompatible software licenses.

Examples of applications and their plug-ins include:

  • Email clients use plug-ins to decrypt and encrypt email (Pretty Good Privacy)
  • Graphics software use plug-ins to support file formats and process images (Adobe Photoshop)
  • Media players use plug-ins to support file formats and apply filters (foobar2000, GStreamer, Quintessential, VST, Winamp, XMMS)
  • Packet sniffers use plug-ins to decode packet formats (OmniPeek)
  • Remote sensing applications use plug-ins to process data from different sensor types (Opticks)
  • Software development environments use plug-ins to support programming languages (Eclipse, jEdit, MonoDevelop)
  • Web browsers use plug-ins to play video and presentation formats (Flash, QuickTime, Microsoft Silverlight, 3DMLW)
  • Some digital mixing consoles allow plug-ins to extend features such as reverberation effects, equalization and compression.

Bookmark and Share

Continue Reading 27 June, 2008 at 13:37 Leave a comment

Declarative Services and bnd

I really like declarative services because it satisfies one of my main instincts: less is more. You can get services to work in a very easy way. However, the XML is still, well, ehh, XML. Obviously, the unnecessary verboseness of XML still offends my instincts. XML is useful in machine to machine communications because it is well standardized but it should have no place in human-machine interaction.

I therefore, a long time ago, added a facility in bnd to create the declarative services from a manifest header. For simplicity, I like the static 1:1 policy/cardinality so that was the default.

     provides:=aQute.command.CommandProcessor; \

This creates the following XML:

 <?xml version='1.0' encoding='utf-8'?>
 <component name=''>
   <implementation class=''/>
     <provide interface='aQute.command.CommandProcessor'/>
   <reference name='threadio'

As the Ruby guys would say: convention over configuration. However, not all services are 1:1 static and the syntax for specifying other cardinalities is kind of ugly. You need to list the reference names in special directives for policy:, multiple:, and optional: :

     provides:=aQute.command.CommandProcessor; \
     threadio=aQute.threadio.ThreadIO; \
     dynamic:=threadio; \
     multiple:=threadio; \



9 June, 2008 at 23:44 Leave a comment

Older Posts

IT Passion’s Store



Get the Source
OSGi supporter
JUG Milano

Upcoming Events


Blog Stats

  • 373,056 hits

My PageRank

What's My Google PageRank?