The document describes Siemens' workflow for OSGi development using bndtools. It involves using a version="latest" configuration to reference dependencies from a local or remote Developer OBR (DevOBR) containing stable releases. Continuous integration builds and tests code and releases new versions to the remote read-only DevOBR. This allows developers to work on the latest code while ensuring dependencies can be resolved and past builds reproduced. The workflow aims to provide modularity, partial checkouts, automatic builds, and tools for semantic versioning and dependency management, but some additional tool features could improve the process.

1. OSGi Community Event 2012
Dieter Bogdoll, Marian Grigoras
Siemens AG, Corporate Technology
Workflow for development, release
and versioning with
Real-world challenges
Copyright © Siemens AG 2012. All rights reserved.
Workflow for development, release
and versioning with OSGi / bndtools

2. Page 2 OSGi Workflow
Who we are
Research group within Siemens CorporateTechnology
with diverse skills
computer science
mathematics
physics
mechanical engineering
electrical engineering
and diverse commitments with respect
full time
part time
work students
graduate students
phd students
© Siemens AG, Corporate Technology
CorporateTechnology (~10 people)
to development time

3. Page 3 OSGi Workflow
What we do
Customer solutions (=Siemens business
technologies (and other machine learning algorithms).
Paperware doesn‘t cut it for our customers
they want to have software prototypes
Rapid prototyping (solution) and in parallel build up our frameworks and
algorithm toolbox
API backward compatibility not that relevant
but need reproducibility of old projects
© Siemens AG, Corporate Technology
business units) based on neural network
machine learning algorithms).
customers
prototypes or solutions
Rapid prototyping (solution) and in parallel build up our frameworks and
API backward compatibility not that relevant
but need reproducibility of old projects

4. Page 4 OSGi Workflow
LibraryLibrary 1
Java with Eclipse
Several SVN repositories
Continuous Integration (Jenkins) to build, test and create deployable
artifacts
Software Landscape
proj proj proj proj
proj proj proj proj
proj proj proj proj
Solution 1 Solution 2
© Siemens AG, Corporate Technology
Library 2
Continuous Integration (Jenkins) to build, test and create deployable
proj proj proj proj
proj proj proj proj
proj proj proj proj
Solution 2

5. Page 5 OSGi Workflow
Artifact for solution deployment
common for all solutions: launcher
solution specific configuration
complete dependency tree of the solution
Non-devs should be able to create a solution artifact with the latest code
Creation of a solution artifact
should happen on CI
should be archived by CI
© Siemens AG, Corporate Technology
solution automate!
should be able to create a solution artifact with the latest code

6. Page 6 OSGi Workflow
Requirements for a development workflow
Enforced modularity
Use CI to build, test and create artifacts (
Partial checkouts (import in eclipse only the project(s) we want to work on,
dependencies should be automatically handled)
Automatic build in eclipse… (easy to use for new team members)
… and from the command line (mandatory for CI integration)
Overview of module dependencies, e.g. what classes cause an import
(using byte code inspection)
Tool support for semantic versioning: correct semantic versioning needs
manual validation, but tools should make a suggestion
© Siemens AG, Corporate Technology
Requirements for a development workflow
Use CI to build, test and create artifacts (libs and solution artifacts)
Partial checkouts (import in eclipse only the project(s) we want to work on,
dependencies should be automatically handled)
Automatic build in eclipse… (easy to use for new team members)
… and from the command line (mandatory for CI integration)
Overview of module dependencies, e.g. what classes cause an import
Tool support for semantic versioning: correct semantic versioning needs
manual validation, but tools should make a suggestion

7. Page 7 OSGi Workflow
OSGi / bnd / bndtools
OSGi / bnd / bndtools promise to fulfill all requirements
Goal: leverage OSGi services - start with modularity layer
bnd
generates the manifest.mf according to a
no direct manual maintenance of the manifest.mf
bndtools
Eclipse plugin on top of bnd
Ant tasks for command line / CI integration
© Siemens AG, Corporate Technology
promise to fulfill all requirements
start with modularity layer
according to a config file
manifest.mf
Ant tasks for command line / CI integration

8. Page 8 OSGi Workflow
The version keyword
Meaning of version=latest in the bnd
use dependency from workspace if available, otherwise from defined OBRs
Example: ProjA depends on ProjB and ProjC
OBRWorkspace
Proj A*
Proj B*
A-1.0.0
B-1.0.0
C-1.0.0
Default, without ver=latest
Dev expects to debug the workspace version without the need to deploy
to an OBR
© Siemens AG, Corporate Technology
bnd configuration file:
use dependency from workspace if available, otherwise from defined OBRs
ProjC
Workspace
Proj A*
OBR
Proj B*
A-1.0.0
B-1.0.0
C-1.0.0
ver=latest
Dev expects to debug the workspace version without the need to deploy

9. Page 9 OSGi Workflow
Developer OBR (DevOBR)
• OBR holding all bundles developed by the team, as they have been released
for team use
• contains only stable versions, no work
• may include any number of older versions
DevOBR location:
• Local: in the workspace, checked out from SVN repository
• Remote: accessed via http(s)
• No DevOBR
© Siemens AG, Corporate Technology
OBR holding all bundles developed by the team, as they have been released
contains only stable versions, no work-in-progress
may include any number of older versions
Local: in the workspace, checked out from SVN repository

10. Page 10 OSGi Workflow
No DevOBR
• dependencies must come from source repository
• dev working on ProjA must checkout sources of the whole dependency
subtree of ProjA
how do you know which dependencies to check out?
dev works with latest (work-in-progress) sources of each lib in the
dependency subtree
almost impossible to reproduce the context of a particular build
© Siemens AG, Corporate Technology
dependencies must come from source repository
must checkout sources of the whole dependency
how do you know which dependencies to check out?
progress) sources of each lib in the
almost impossible to reproduce the context of a particular build

11. Page 11 OSGi Workflow
Local DevOBR
• on new feature/bugfix, dev must release new bundle to local
commit the changes to SVN
all users need to manually update their local OBR copy
deployment: resolving dependencies results in URLs specific to a developer
machine => won’t work on another machine
• dev must create the solution artifact locally
• non-devs cannot do it
too easy for dev to deploy to customer without committing and versioning
the changes
© Siemens AG, Corporate Technology
, dev must release new bundle to local DevOBR and
all users need to manually update their local OBR copy
deployment: resolving dependencies results in URLs specific to a developer
machine => won’t work on another machine
dev must create the solution artifact locally
too easy for dev to deploy to customer without committing and versioning

12. Page 12 OSGi Workflow
Remote DevOBR
all artifacts in one place
automatic use of newest released bundles
read-only access for devs
preferably only CI has write access into
© Siemens AG, Corporate Technology
automatic use of newest released bundles
preferably only CI has write access into DevOBR

13. Page 13 OSGi Workflow
Force source commit to cause a new version bundle?
several commits with the same bundle version
bundle version 1.0.0 in HEAD means work
large number of artifacts
annoying for devs
Semantic for commit without version bump: let CI check the current status (tests)
© Siemens AG, Corporate Technology
Force source commit to cause a new version bundle?
several commits with the same bundle version
bundle version 1.0.0 in HEAD means work-in-progress for next version
Semantic for commit without version bump: let CI check the current status (tests)

14. Page 14 OSGi Workflow
Should DevOBR overwrite an existing bundle
with the same version?
source repo and DevOBR in sync
default behaviour of bnd
over time, multiple artifacts with the same bundle version
© Siemens AG, Corporate Technology
overwrite an existing bundle
over time, multiple artifacts with the same bundle version

15. Page 15 OSGi Workflow
Recap: target development workflow
Dev Workspace
Dev WorkspaceDev
Workspace
SVN
repository
Continuous
Integration
Dev OBR
3rdParty OBR
Manual
updates
© Siemens AG, Corporate Technology
Recap: target development workflow
• use version=latest
• all checked out sources
• other OBRs
• src repo contains wip
• CI builds / tests / pushes to
DevOBR
• remote read-only DevOBR
• does NOT overwrite
• CI can collect deployment
artifacts
3rdParty OBR
Manual
updates

16. Page 16 OSGi Workflow
Typical development sequences
Dev SVN
wip commit
no version bump
A-1.0.0
A-1.0.1
release-for-team commit
bump version
© Siemens AG, Corporate Technology
CI DevOBR
A-1.0.0
build, test
release
Do NOT overwrite
existing version
build, test
release
Put A-1.0.1 in DevOBR

17. Page 17 OSGi Workflow
Conclusions
• we like OSGi modularity
• using bnd and bndtools feels like the right way to develop
• for our target workflow we still need tool support for a few features
• surprised there is no default workflow encompassing:
dev, source repo, CI, OBR
• would help new teams have an easier start, if the tool suggested (and
supported) a default workflow process started at the
© Siemens AG, Corporate Technology
feels like the right way to develop OSGi
for our target workflow we still need tool support for a few features
surprised there is no default workflow encompassing:
help new teams have an easier start, if the tool suggested (and
process started at the bnd hackatron 2012

18. Page 18 OSGi Workflow
Thank you for your attention!
Dieter Bogdoll
email: dieter.bogdoll@siemens.com
Siemens AG
Corporate Technology
© Siemens AG, Corporate Technology
Marian Grigoras
email: marian.grigoras@siemens.com