We've neglected to keep up-to-date the JcrRepository value for the Repository.REP_VERSION_DESC descriptor. Rather than have a hard-coded value, we should dynamically pull this from the Maven-produced artifacts. Luckily, the manifest (see attached, which is a sample from the "1.1-SNAPSHOT" version) has two fields containing the version information, and both originate from the version value used in the POM:

Bundle-Version: 1.1.0.SNAPSHOT
Implementation-Version: 1.1-SNAPSHOT

This MANIFEST.MF can be read in JcrRepository with code similar to:

InputStream stream = getClass().getResourceAsStream("/META-INF/MANIFEST.MF");
Properties props = new Properties();
props.load(stream);

Note the "Implementation-Version" looks like it matches the value in the POM exactly, whereas the "Bundle-Version" is the OSGi interpretation of the value in the POM.

Also, there are several other fields that are obtained from the POM that could be use for other descriptors (tho we'd probably have to change the corresponding values in the POM to match what we want to have in the descriptor):

Bundle-Name: ModeShape JCR implementation
Bundle-Vendor: JBoss, a division of Red Hat
Bundle-Version: 1.1.0.SNAPSHOT
Bnd-LastModified: 1267818154059
Bundle-License: http://repository.jboss.org/licenses/lgpl-2.1.txt
Bundle-Description: ModeShape implementation of the JCR API

The POM is also directly placed within the JAR file (at META-INF/maven/org.modeshape/modeshape-jcr/pom.properties), but this approach requires hard-coding the path and only has three properties. Here's the complete file:

version=1.1-SNAPSHOT
groupId=org.modeshape
artifactId=modeshape-jcr