[JAVA-272] OSGi Manifest is incorrect Created: 15/Feb/11  Updated: 18/Jun/12  Resolved: 11/May/12

Status: Closed
Project: Java Driver
Component/s: None
Affects Version/s: 2.4
Fix Version/s: 2.8.0

Type: Bug Priority: Major - P3
Reporter: Eike Stepper Assignee: Bryan Reinero
Resolution: Done Votes: 9
Labels: None
Remaining Estimate: 3 hours, 30 minutes
Time Spent: 30 minutes
Original Estimate: 4 hours
Environment:

OSGi / Java



 Description   

The OSGi bundle MANIFEST.MF file looks incorrect:

Bundle-Name: MongoDB
Bundle-SymbolicName: com.mongodb
Bundle-Version: 2.1.0
Export-Package: com.mongodb, com.mongodb.io, com.mongodb.util, com.mon
godb.gridfs, org.bson, org.bson.util, org.bson.types, org.bson.io

Shouldn't that be 2.4.0?

Please also note that (odd enough) the bundle version number is not used as a default version for exported packages that do not explicitely specify an export version. As a consequence one can not import these packages with a well-defined version range. Both issues require me to repackage this bundle, which also creates a potential for deployment duplication.

Say, do you plan to provide an Equinox p2 repository for your OSGi bundles?



 Comments   
Comment by Jeffrey Yemin [ 18/Jun/12 ]

Closing for 2.8.0 release.

Comment by auto [ 25/May/12 ]

Author:

{u'login': u'jyemin', u'name': u'Jeff Yemin', u'email': u'jeff.yemin@10gen.com'}

Message: JAVA-272: Cleaning of the manifest. Added Bundle-License, improved Bundle-Name and Bundle-SymbolicName, removed Bundle-ClassPath
Branch: master
https://github.com/mongodb/mongo-java-driver/commit/e89633f9266a50c2d899adf086deefa08aeae1c2

Comment by auto [ 25/May/12 ]

Author:

{u'login': u'jyemin', u'name': u'Jeff Yemin', u'email': u'jeff.yemin@10gen.com'}

Message: JAVA-272: To deal with the OSGi/Maven version name incompatibilities, added ability to use a different version name for maven and OSGi. So the Maven POM that we upload would have a version like 2.8.0-RC1 or 2.8.0, while the corresponding Bundle-Version in MANIFEST.MF would be 2.8.0.RC1 or 2.8.0.RELEASE. Hopefully this will work for both Maven and OSGi users, as it's the strategy used by, for example the maven-bundle-plugin
Branch: master
https://github.com/mongodb/mongo-java-driver/commit/91e4135b2faf666092acf036838b9caa087137ec

Comment by Jeffrey Yemin [ 25/May/12 ]

I've done a bunch of testing of version ranges with maven, and though they are not widely used, I'm not comfortable changing the naming conventions of the jars that we publish to the maven central repository. Instead, I'm going to follow the convention used by the maven bundle plugin, and convert (manually for now, using build.properties) OSGi-incompatible maven versions into OSGi-compatible ones. So it will look like this:

Maven version OSGi version
2.8.0-RC1 2.8.0.RC1
2.8.0 2.8.0.RELEASE

I've also changed some of the values in the manifests, including

  • Added Bundle-License
  • Changed Bundle-Name to MongoDB Java Driver
  • Changed Bundle-SymbolicName to org.mongodb.mongo-java-driver
  • Removed Bundle-ClassPath

So the full manifest is going to look like:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.8.2
Created-By: 1.6.0_31-b04-415-11M3635 (Apple Inc.)
Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
Bundle-ManifestVersion: 2
Bundle-Name: MongoDB Java Driver
Bundle-SymbolicName: org.mongodb.mongo-java-driver
Bundle-Version: 2.8.0.RELEASE
Import-Package: javax.management, javax.net, javax.net.ssl
Export-Package: com.mongodb;version="2.8.0.RELEASE",com.mongodb.io;ver
 sion="2.8.0.RELEASE",com.mongodb.util;version="2.8.0.RELEASE",com.mon
 godb.gridfs;version="2.8.0.RELEASE",org.bson;version="2.8.0.RELEASE",
 org.bson.util;version="2.8.0.RELEASE",org.bson.util.annotations;versi
 on="2.8.0.RELEASE",org.bson.types;version="2.8.0.RELEASE",org.bson.io
 ;version="2.8.0.RELEASE"

while the maven POM will have a version of 2.8.0 and the name of the jar file will be mongo-java-driver-2.8.0.jar.

Please let me know if you see any problems with this.

Comment by Bryan Reinero [ 11/May/12 ]

Tested loaded the driver as a bundle in a stand-alone instance of Equinox. The bundle generates no errors on install.

Comment by kaleigh smith [ 11/Apr/12 ]

I've built the most recent version with 'ant compile jar' and I am still having problems with javax.management when I try to create a Mongo connection on a webapp deployed through Glassfish. I've made the app dependent on my newly built 2.8.0 jar.

I was wondering if anyone can confirm that the current manifest file is correct and that javax.management is available to the Mongo Java driver. Thanks!

Comment by Jeffrey Yemin [ 09/Apr/12 ]

Scheduled for inclusion in 2.8.0

Comment by Camille Fournier [ 06/Apr/12 ]

What's the status of getting this fixed and released? We're having a lot of pain due to this issue and it seems like it's been outstanding for over a year now.
Thanks.

Comment by Jeffrey Yemin [ 12/Mar/12 ]

We will. It's just that we've been using lowercase until now internally, so wanted to check that we really need to change.

Thanks for all the feedback.

Comment by Oliver Gierke [ 12/Mar/12 ]

Well, not sure 100% :/. Why not stick to upper case?

Comment by auto [ 12/Mar/12 ]

Author:

{u'login': u'jyemin', u'name': u'Jeff Yemin', u'email': u'jeff.yemin@10gen.com'}

Message: JAVA-272: Fixed OSGi manifest
Branch: master
https://github.com/mongodb/mongo-java-driver/commit/605946d6332c0e10650a1f77822ba042d1c31365

Comment by Jeffrey Yemin [ 12/Mar/12 ]

So we can't use lowercase release candidate strings like 2.8.0.rc1 because "rc1" > "RELEASE" lexicographically, right?

Comment by Oliver Gierke [ 12/Mar/12 ]

Awesome, thanks!

Comment by Oliver Gierke [ 12/Mar/12 ]

That's what I was describing in my comment above. OSGi requires the 3rd digit to be purely numerical, which is why e.g. Spring uses the suggested version number scheme. Note that if you're moving to 2.8.0.BUILD-SNAPSHOT and release e.g. 2.8.0.M1 you cannot release a plain 2.8.0 for the final release anymore as Maven will fall back to lexical version comparison so that you need to use somthing like 2.8.0.RELEASE to be lexically "newer" than the milestones released before.

Comment by Jeffrey Yemin [ 12/Mar/12 ]

So now it looks like this:

 
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.8.2
Created-By: 1.6.0_29-b11-402-11M3527 (Apple Inc.)
Bundle-ManifestVersion: 2
Bundle-Name: MongoDB
Bundle-SymbolicName: com.mongodb
Bundle-ClassPath: mongo-java-driver-2.8.0.BUILD-SNAPSHOT.jar
Bundle-Version: 2.8.0.BUILD-SNAPSHOT
Import-Package: javax.management, javax.net, javax.net.ssl
Export-Package: com.mongodb;version="2.8.0.BUILD-SNAPSHOT",com.mongodb
 .io;version="2.8.0.BUILD-SNAPSHOT",com.mongodb.util;version="2.8.0.BU
 ILD-SNAPSHOT",com.mongodb.gridfs;version="2.8.0.BUILD-SNAPSHOT",org.b
 son;version="2.8.0.BUILD-SNAPSHOT",org.bson.util;version="2.8.0.BUILD
 -SNAPSHOT",org.bson.types;version="2.8.0.BUILD-SNAPSHOT",org.bson.io;
 version="2.8.0.BUILD-SNAPSHOT"

Comment by Jeffrey Yemin [ 12/Mar/12 ]

Seems like the problem is with the "-" between "0" and "SNAPSHOT". OSGi seems to want that to be another ".". So there seems to be an incompatibility between Maven style snapshot version number and OSGi. In practice I don't think this will be a problem, as all releases of the Java driver (final and release candidate) will conform to OSGi standards.

It looks like Maven 3 is moving towards OSGi compatibility by using this form for snapshots: x.y.z.BUILD-SNAPSHOT, so we can certainly do the same for the Java driver.

Comment by Oliver Gierke [ 12/Mar/12 ]

Well, in 2.8.0-SNAPSHOT it is not. If the final ones will be 2.8.0 - that's fine. Snapshot version will not be usable in an OSGi container then.

Comment by Jeffrey Yemin [ 07/Mar/12 ]

I don't understand. The third digit is numerical.

Regardless, assuming that 2.8.0-SNAPSHOT will become 2.8.0 in the actual release of the jar, does it look good?

Comment by Oliver Gierke [ 07/Mar/12 ]

That doesn't look too good as 2.8.0-SNAPSHOT aren't valid OSGi version numbers. The 3rd digit is required to be numerical, which is one of the reasons e.g. SpringSource uses 1.2.0.BUILD-SNAPSHOT style versions to satisfy OSGi on the one side (3rd digit numerical) as well as Maven (snapshot versions ending on -SNAPSHOT).

Comment by Jeffrey Yemin [ 14/Feb/12 ]

How does this look:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.8.2
Created-By: 1.6.0_29-b11-402-11M3527 (Apple Inc.)
Bundle-ManifestVersion: 2
Bundle-Name: MongoDB
Bundle-SymbolicName: com.mongodb
Bundle-ClassPath: mongo-java-driver-2.8.0-SNAPSHOT.jar
Bundle-Version: 2.8.0-SNAPSHOT
Import-Package: javax.management, javax.net, javax.net.ssl
Export-Package: com.mongodb;version="2.8.0-SNAPSHOT",com.mongodb.io;ve
 rsion="2.8.0-SNAPSHOT",com.mongodb.util;version="2.8.0-SNAPSHOT",com.
 mongodb.gridfs;version="2.8.0-SNAPSHOT",org.bson;version="2.8.0-SNAPS
 HOT",org.bson.util;version="2.8.0-SNAPSHOT",org.bson.types;version="2
 .8.0-SNAPSHOT",org.bson.io;version="2.8.0-SNAPSHOT"

Comment by Oliver Gierke [ 30/Nov/11 ]

Is there a chance we can see a correct MANIFEST.MF in the upcoming release? With 2.7.1 packages still are not exported in a particular version which makes clients need to refer to the packages using version="" which is pretty much the opposite of what you want to do when using OSGi. I actually don't care that much about the way the MANIFEST.MF is being generated but using Bundlor is just a metter of adding a Maven plugin or Ant task to your project's build. It doesn't impose any dependency on clients using the driver.

Comment by Jean-Pierre Bergamin [ 24/Nov/11 ]

We still have to create correct OSGi manifest headers ourselves - for every release. The ones you're providing are lacking version information and it's just a matter of time until they get out of sync again.

Why the hesitation to include bundlor or bnd in the build process to create the manifest automatically? OSGi headers are not supposed to be maintained by hand.

Comment by Antoine Girbal [ 28/Oct/11 ]

Since the driver lets you override the socket type, for example to use SSL, we need to fix manifest further.

This manifest contains: Import-Package: javax.management
but it should have: Import-Package: javax.management, javax.net, javax.net.ssl

When the current driver is deployed to an OSGI container the following message appears.: org.eclipse.virgo.kernel.osgi.framework.ExtendedClassNotFoundException: javax.net.SocketFactory in KernelBundleClassLoader: [bundle=com.mongodb_2.6.5]

Comment by auto [ 20/Oct/11 ]

Author:

{u'login': u'rgnitz', u'name': u'Ryan', u'email': u'rgnitz@gmail.com'}

Message: Merge pull request #49 from efroese/master

JAVA-272 - OSGi Manifest is incorrect
Branch: master
https://github.com/mongodb/mongo-java-driver/commit/c60502dc81c72c35cf3b986476b8f75fe87f79d4

Comment by Erik Froese [ 20/Oct/11 ]

I've submitted a pull request [1] with the updated MANIFEST.MF. I just had to add javax.net to the Import-Package directive. It includes a snippet of the stacktrace.

I don't have a simple example but I can tell you that trying to activate this OSGi component [2] in Apache Felix fails.

[1] https://github.com/mongodb/mongo-java-driver/pull/49
[2] http://goo.gl/cgAZu

Comment by Jean-Pierre Bergamin [ 19/Oct/11 ]

I provided this pull request, already a couple of months ago (see comment above).
It would be very helpful if the automatic generation of the manifest could be included in your build process.

Comment by Scott Hernandez (Inactive) [ 18/Oct/11 ]

What patch did you apply, and do you have an example which shows the problem?

Comment by Erik Froese [ 18/Oct/11 ]

This is still an issue with 2.6.5. The driver will not work in Apache Felix without patching the MANIFEST.MF. Please fix.

Comment by Narasimhan Vallur [ 04/Oct/11 ]

the manifest is totally not compatible with OSGI right now. Complains on Javax.net.SocketFactory class definition not found. Please generate and include a proper manifest which would work for any osgi ASAP else it is a no go for services or web services using mongo.

Generating the manifest is a good option but if we generate then we will be missing something everytime and would break somewhere else, so testing becomes very hard for us.

Comment by Jean-Pierre Bergamin [ 08/Jun/11 ]

Please see https://github.com/mongodb/mongo-java-driver/pull/33 to have the MANIFEST.MF generated automatically.

Comment by auto [ 16/May/11 ]

Author:

{u'login': u'scotthernandez', u'name': u'Scott Hernandez', u'email': u'scotthernandez@gmail.com'}

Message: JAVA-272: updated osgi info; still need to automate
Branch: master
https://github.com/mongodb/mongo-java-driver/commit/6ed192d5945303b183452e20087ae6703173464d

Comment by DieterĀ  Guendisch [ 21/Apr/11 ]

Please provide a correct osgi manifest. Otherwise it's unnecessarily cumbersome to get the driver up and running in any osgi container...

Comment by Max Bridgewater [ 17/Apr/11 ]

Any plan to address this Manifest issue? In the 2.5.3 jar of April 6th, the javax.management package is still missing. Same as Bundle-Version is still 2.1.0.

Comment by Daniele Dellafiore [ 24/Mar/11 ]

There is problem in the manifest, other then the wrong version number.
Without this line:

Import-Package: javax.management

you'll get a NoDefClassFound when trying to load a Mongo instance, addressing a missing javax.management.JMException

Comment by Eike Stepper [ 21/Feb/11 ]

Any OSGi Platform would do. Eclipse/Equinox is the reference implementation and included in the popular IDE. Others are listed at http://www.osgi.org/Markets/OpenSource

Comment by Scott Hernandez (Inactive) [ 20/Feb/11 ]

Is there a test environment you suggest to verify the change?

Comment by Eike Stepper [ 15/Feb/11 ]

I repackaged with this manifest:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: MongoDB
Bundle-SymbolicName: com.mongodb
Bundle-Version: 2.4.0.qualifier
Bundle-ClassPath: mongo-2.4.jar
Export-Package: com.mongodb;version="2.4.0",
com.mongodb.gridfs;version="2.4.0",
com.mongodb.io;version="2.4.0",
com.mongodb.util;version="2.4.0",
org.bson;version="2.4.0",
org.bson.io;version="2.4.0",
org.bson.types;version="2.4.0",
org.bson.util;version="2.4.0"
Created-By: 1.6.0_22-b04-307-10M3261 (Apple Inc.)
Ant-Version: Apache Ant 1.8.1

Generated at Thu Feb 08 08:51:53 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.