MANIFEST.MF and feature.xml versioning rules

I’m forever forgetting what the rules are for dependency declarations in MANIFEST.MF and feature.xml for osgi plugins and features. And Googling often results in frustration rather than an answer. So, because today I actually found a concise list of the rules, I thought I’d repost them here, with some minor edits to help clarify.

OSGi Plugin Version Ranges

Dependencies on bundles and packages have an associated version range which is specified using an interval notation: a square bracket “[” or “]” denotes an inclusive end of the range and a round bracket “(” or “)” denotes an exclusive end of the range. Where one end of the range is to be included and the other excluded, it is permitted to pair a round bracket with a square bracket. The examples below make this clear.

If a single version number is used where a version range is required this does not indicate a single version, but the range starting from that version and including all higher versions.

There are four common cases:

  • A “strict” version range, such as [1.2.3,1.2.3], which denotes that version and only that version. 
  • A “half-open” range, such as [1.2.3,2.0.0), which has an inclusive lower limit and an exclusive upper limit, denoting version 1.2.3 and any version after this, up to, but not including, version 2.0.0. 
  • An “unbounded” version range, such as 1.2.3, which denotes version 1.2.3 and all later versions.
  • No version range, which denotes any version will be acceptable. NOT RECOMMENDED

The complete text of the above snippet can be seen here (or here as PDF).

Example:

Require-Bundle: org.eclipse.core.runtime;bundle-version="[3.4.0,4.0.0)", org.eclipse.core.resources;bundle-version="[3.4.0,4.0.0)", org.eclipse.ui.ide;bundle-version="[3.4.0,4.0.0)", org.eclipse.ui.navigator;bundle-version="3.5.100", com.ibm.icu

See also:

In terms of feature manifest (feature.xml) rules, help.eclipse.org has pretty good documentation, but the most important thing to remember – and what I often have to look up – is how to state the matching rules for required upstream features & plugins. Experience says it’s always better to state things explicitly so there’s no downstream guesswork needed and anyone reading your manifest knows EXACTLY what version(s) are required for or compatible with your feature. Plus, while YOU might be using PDE UI to build, someone else might be using Tycho and Maven, and every tool can interpret missing metadata their own way.

When in doubt, spell it out.

Valid values and processing are as follows:

  • if version attribute is not specified, the match attribute (if specified) is ignored.
  • perfect – dependent plug-in version must match exactly the specified version. If “patch” is “true”, “perfect” is assumed and other values cannot be set. [1.2.3,1.2.3]
  • equivalent - dependent plug-in version must be at least at the version specified, or at a higher service level (major and minor version levels must equal the specified version). [1.2.3,1.3)
  • compatible - dependent plug-in version must be at least at the version specified, or at a higher service level or minor level (major version level must equal the specified version). [1.2.3,2.0)
  • greaterOrEqual - dependent plug-in version must be at least at the version specified, or at a higher service, minor or major level. 1.2.3 

The complete text of the above snippet can be seen here.

Example:

<requires>
  <import feature="org.eclipse.m2e.feature" version="1.0.0" match="compatible"/>
  <import feature="org.maven.ide.eclipse.wtp.feature" version="0.13.0" match="greaterOrEqual"/>
  <plugin id="ch.qos.logback.classic" version="0.9.27.v20110224-1110" match="greaterOrEqual"/>
  <plugin id="ch.qos.logback.core" version="0.9.27.v20110224-1110" match="greaterOrEqual"/>
  <plugin id="ch.qos.logback.slf4j" version="0.9.27.v20110224-1110" match="greaterOrEqual"/>
  <plugin id="org.slf4j.api" version="1.6.1.v20100831-0715" match="compatible"/>
  <plugin id="com.ning.async-http-client" version="1.6.3.201106061504" match="equivalent"/>
  <plugin id="org.jboss.netty" version="3.2.4.Final-201106061504" match="perfect"/>
  <plugin id="org.hamcrest.core" version="1.1.0.v20090501071000" match="equivalent"/>
</requires>

Reference: MANIFEST.MF and feature.xml versioning rules from our JCG partner Nick Boldt  at the DivByZero blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


× three = 18



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close