Java Reference
In-Depth Information
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;
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
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 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.
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)",;version="[1.0, 2.0)"
Bundle-ManifestVersion: 2
Next, you need to provide a SpecialOffer implementation:
Search WWH ::

Custom Search