Search icon
Arrow left icon
All Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletters
Free Learning
Arrow right icon
Eclipse Plug-in Development Beginner's Guide - Second Edition

You're reading from  Eclipse Plug-in Development Beginner's Guide - Second Edition

Product type Book
Published in Aug 2016
Publisher
ISBN-13 9781783980697
Pages 458 pages
Edition 2nd Edition
Languages
Author (1):
Alex Blewitt Alex Blewitt
Profile icon Alex Blewitt

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
1. Creating Your First Plug-in 2. Creating Views with SWT 3. Creating JFace Viewers 4. Interacting with the User 5. Working with Preferences 6. Working with Resources 7. Creating Eclipse 4 Applications 8. Migrating to Eclipse 4.x 9. Styling Eclipse 4 Applications 10. Creating Features, Update Sites, Applications, and Products 11. Automated Testing of Plug-ins 12. Automated Builds with Tycho 13. Contributing to Eclipse Using OSGi Services to Dynamically Wire Applications Pop Quiz Answers 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.

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $15.99/month. Cancel anytime}