Book Image

Eclipse Plug-in Development Beginner's Guide - Second Edition

By : Alex Blewitt
Book Image

Eclipse Plug-in Development Beginner's Guide - Second Edition

By: Alex Blewitt

Overview of this book

Eclipse is used by everyone from indie devs to NASA engineers. Its popularity is underpinned by its impressive plug-in ecosystem, which allows it to be extended to meet the needs of whoever is using it. This book shows you how to take full advantage of the Eclipse IDE by building your own useful plug-ins from start to finish. Taking you through the complete process of plug-in development, from packaging to automated testing and deployment, this book is a direct route to quicker, cleaner Java development. It may be for beginners, but we're confident that you'll develop new skills quickly. Pretty soon you'll feel like an expert, in complete control of your IDE. Don't let Eclipse define you - extend it with the plug-ins you need today for smarter, happier, and more effective development.
Table of Contents (24 chapters)
Eclipse Plug-in Development Beginner's Guide Second Edition
Credits
Foreword
About the Author
Acknowledgments
About the Reviewers
www.PacktPub.com
Preface
Index

Services overview


In an Eclipse or OSGi runtime, each individual bundle is its own separate module, which has explicit dependencies on library code via Import-Package, Require-Bundle, or Require-Capability. These express static relationships and provide a way of configuring the bundle's classpath.

However, this presents a problem. If services are independent, how can they use contributions provided by other bundles? In Eclipse's case, the Extension Registry provides a means for code to look up providers. In a standalone OSGi environment, OSGi services provide a similar mechanism.

A service is an instance of a class that implements a service interface. When a service is created, it is registered with the services framework under one (or more) interfaces, along with a set of properties. Consumers can then get the service by asking the framework for implementers of that specific interface.

Note

Services can also be registered under an abstract class, but this is not recommended. Providing a service interface exposed as an abstract class can lead to unnecessary coupling of client to implementation.

This separation allows the consumer and producer to depend on a common API bundle, but otherwise be completely disconnected from one another. This allows both the consumer and producer to be mocked out or exchanged with different implementations in the future.