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

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…

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

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…

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