OSGi Versioning & Testing

Chris Aniszczyk EclipseSource http://aniszczyk.org Paul VanderLei Band XI International

T elematics - O n- A - ST ick
Sample from upcoming book equinoxosgi.org
Example project in EclipseRT wiki.eclipse.org/Toast
OSGi Versioning and Testing | © Copyright 2009 EclipseSource & Band XI International; made available under EPL v1.0

Versioning
Evolving API
Tools
Issues
Summary

“ Software versioning is the process of assigning either unique version names or unique version numbers to unique states of computer software.”
Versioning is relative though…

Versioning is a marketing thing…
User’s don’t really care about versions…
Users just want to know if the version of the software they are running is current…
e.g., Ubuntu
Feisty Fawn – 7.04
Gutsy Gibbon – 7.10
Hardy Heron – 8.04

Version numbers are like dog tags *
Primarily used in an event of emergency…
OSGi Versioning and Testing | © Copyright 2009 EclipseSource & Band XI International; made available under EPL v1.0 * http://www.codinghorror.com/blog/archives/000793.html

Dependencies are defined on the module and package level
Import-Package
Require-Bundle
Ranges allow for flexibility
Import-Package: org.easymock;version=[2.4.0,3.0.0)

major.minor.micro.qualifier
major – An incompatible update; breaking API
minor – A backward compatible update; API stable
micro – A bug fix; no API changes
qualifier – build date; lexigraphic
Versions should encode compatibility* at the bundle and package level
OSGi Versioning and Testing | © Copyright 2009 EclipseSource & Band XI International; made available under EPL v1.0 *http://wiki.eclipse.org/Version_Numbering

Let’s evolve our GPS API…

Toast on a plane… we add height…

Management now wants an altimeter!

We broke API, need to fix versions!

Managing versions is important and painful
At Eclipse, we learned this lesson and have many experiences in dealing with maintaining and evolving API
Other projects eventually learn the importance of versioning…

OSGi Versioning and Testing | © Copyright 2009 EclipseSource & Band XI International; made available under EPL v1.0 “ I still believe a an official compatibility statement are in order. It includes a definition of the API and a separate definition of the SPI, and possible a third definition of the Configuration. I bet everyone would back such statement, would clarify the "unbreakable“ parts, and what is "features of your own risk" and so on.”

OSGi Versioning and Testing | © Copyright 2009 EclipseSource & Band XI International; made available under EPL v1.0 http://commons.apache.org/collections/compatibility.html “ Commons collections 3.0 is binary compatible with version 2.1 and 2.0 except for certain methods on one class. As the release was a major version, this is permitted, however it was unintentional and an error … the chosen solution is to provide a work around by releasing v2.1.1 and v3.1.”

Users need to understand the contract when using your software…
Good fences make for good neighbors!
Binary compatibility is important

Binary compatibility is important
Maintaining binary compatibility is complex
Eclipse puts API on an altar…
Since Eclipse 3.4, Eclipse uses tools to manage and evolve API…
OSGi Versioning and Testing | © Copyright 2009 EclipseSource & Band XI International; made available under EPL v1.0 *http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html

Assists developers in API maintenance by reporting API defects such as binary incompatibilities, incorrect bundle version numbers and API usage.
Let’s revisit the GPS example…

Version number problems and quickfixes…

Let’s unknowingly break API…

Never break API again unless you want to!

Understand API changes…

Getting proper version ranges correct is difficult if there’s no consistent semantics
e.g., log4j case… [1.2.0,1.3.0) or [1.2.0,2.0.0) ?
Not all bundles are versioned properly in repositories
Tooling doesn’t cover packages yet…

OSGi versions encode compatibility!
Don’t treat bundle versions like a marketing number
Scope your version ranges properly

Good Practices
Sample Application
Unit Testing
System Testing
Remaining Issues

Write your application as POJOs (plain-old-java-objects)
No Service Trackers!
Whiteboard Pattern is tricky
Pay attention to dependencies
Unit testing depends on getting this right

Use Junit
Use mock objects (EasyMock, jMock...)
Minimize delays
No human interaction
Do TDD
OSGi Versioning and Testing | © Copyright 2009 EclipseSource & Band XI International; made available under EPL v1.0 “… I think that developers who can’t cope with any level of TDD shouldn’t be coding at all…”

Terminology
Unit under test (UUT)
Test harness
Test each POJO on its own (no OSGi)
Mock each dependency

OSGi Versioning and Testing | © Copyright 2009 EclipseSource & Band XI International; made available under EPL v1.0 get location Log Emergency Servlet GPS Channel Airbag Mock GPS Mock Channel Emergency Monitor Mock Airbag

Keep the test case in a separate project
But POJO is not visible
Solution:

Dependencies

Test as much of system as possible
OSGi is present
Test full system flow
Test bundles coming and going

log get location OSGi Versioning and Testing | © Copyright 2009 EclipseSource & Band XI International; made available under EPL v1.0 deploy Log Mock Log Emergency Servlet Channel GPS Emergency Monitor Airbag Mock Airbag Test Case

Normal Plug-in Project

PDE Junit test infrastructure
uses Equinox extensions
Declarative Services
uses OSGi services

Junit instantiates the test case as usual
setup()
testEmergency()
Problem: no way to obtain:
bundle context
mock airbag
mock log

Instantiates the test case as a component
DS dependency injection
setAirbag(<our mock airbag>)
setLog(<our mock log>)
startup()
Problem:
This instance is never used by Junit!

Still very tricky
Not well-supported by PDE tooling
Validation by logging is fragile

Get the slides: tinyurl.com/osgiVT
Get the code: wiki.eclipse.org/Toast
Get the book: equinoxosgi.org

OSGi Versioning & Testing

by Chris Aniszczyk

Accessibility

Upload Details

Usage Rights

1 Embed 18

Statistics

OSGi Versioning & Testing Presentation Transcript