Developing a simple OSGi-based web application - Enterprise OSGi in Action - page 44

Let's define an interface that can be implemented by everything that describes a
special offer.

Listing 2.5 The SpecialOffer interface

package fancyfoods.offers;

import fancyfoods.food.Food;

public interface SpecialOffer {

public Food getOfferFood();

public String getDescription();

}
It relies on another interface for Food . (This is a food shop—you need food!)

Listing 2.6 The Food interface

package fancyfoods.food;

public interface Food {

String getName();

double getPrice();

int getQuantityInStock();

}
To keep the application modular, these interfaces should go in their own bundle,
fancyfoods.api . The fancyfoods.api bundle should export the fancyfoods.offers
and fancyfoods.food packages. Keeping shared interfaces in an API bundle is a good
OSG i practice; it ensures that only one copy of the interface is on the classpath,
and that implementations can be swapped around without worrying about interbun-
dle dependencies.

EXPOSING SERVICES WITH BLUEPRINT
What we'd like is a way of registering (or publishing) special offers for each depart-
ment, without anyone having to maintain a central list of what offers are available.
Enter Blueprint. Let's define a third bundle, fancyfoods.department.chocolate .
The manifest for fancyfoods.department.chocolate should declare a dependency
on the fancyfoods.offers package:

Manifest-Version: 1.0
Bundle-Blueprint: OSGI-INF/blueprint/*.xml
Bundle-SymbolicName: fancyfoods.department.chocolate
Bundle-Version: 1.0.0
Import-Package: fancyfoods.offers;version="[1.0, 2.0)",
fancyfoods.food;version="[1.0, 2.0)"
Bundle-ManifestVersion: 2
Next, you need to provide a SpecialOffer implementation: