Missing version in osgi manifest package exports

[GoogleCodeExporter]

Please consider adding version information to the Export-package entries in 
MANIFEST.MF.

Eclipse apparently has a policy to only depend on external dependencies with 
package imports. There is a h2 v1.1 bundle published at 
http://download.eclipse.org/tools/orbit/downloads/ by eclipse, which includes 
versioned package exports. Sadly, it takes precedence over an unversioned 
package export, even if the bundle itself has a higher version number.

Anyway, if you could add versions to the package exports, the h2 jar could be 
used as-is in an eclipse installation.

The format for that is something like:

Export-Package: org.h2;version="1.1.117",...

I haven't had a chance to build h2 myself, but if pattern substitution works 
the way I think it does, then the manifest template could look like:

Export-Package: org.h2;version="${version}",...

It is also worth noting that in your manifest, only a couple of packages are 
exported. Is there a reason why this list is so short?

See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=337106

Original issue reported on code.google.com by *gn...@b2international.com on 3 Mar 2011 at 2:10

[GoogleCodeExporter]

Just to put that right: Eclipse has no mandatory policy to only depend on 
external dependencies with package imports. It's a general best practice, for 
good reasons. If we wouldn't do that, you'd have no chance altogether to 
replace the bundle with one of your choice, maybe one with some bugs fixed.

Import-Package and Require-Bundle relate to each other similar to interfaces 
and concrete classes in Java. They are the "What do I want?" and the "Who's 
supposed to provide it?" ;-)

A common mistake is to assume that the bundle version acts as a default value 
for the versions of the exported packages. No explicit version on an exported 
package means it doesn't have any version. And a package without version can 
not be imported selectively by consumers.

Original comment by eike.ste...@googlemail.com on 3 Mar 2011 at 7:38

[GoogleCodeExporter]

OK, what about:

Manifest-Version: 1.0
Implementation-Title: H2 Database Engine
Implementation-URL: http://www.h2database.com
Implementation-Version: 1.3.152
Build-Jdk: 1.6
Created-By: 1.6.0_22-b04-307-10M3261 (Apple Inc.)
Main-Class: org.h2.tools.Console
Bundle-Activator: org.h2.util.DbDriverActivator
Bundle-ManifestVersion: 2
Bundle-Name: H2 Database Engine
Bundle-SymbolicName: org.h2
Bundle-Vendor: H2 Group
Bundle-Version: 1.3.152
DynamicImport-Package: *
Export-Package:
    org.h2;version="1.3.152",
    org.h2.api;version="1.3.152",
    org.h2.fulltext;version="1.3.152",
    org.h2.jdbcx;version="1.3.152",
    org.h2.tools;version="1.3.152",
    org.h2.util;version="1.3.152",
Premain-Class: org.h2.util.Profiler

(Build-Jdk and Created-By will change).

Please note that H2 doesn't have any dependencies. The reason for 
"DynamicImport-Package: *" is that H2 optionally(!) supports SLF4J, Lucene, and 
user defined triggers, functions, aggregate functions, stored procedures, table 
engines, file system implementations, and database event listeners. The class 
names of the user defined classes are persistent in some cases. If there is a 
better way than to use "DynamicImport-Package: *" then please tell me. Some 
people criticized it, but couldn't provide an alternative.

> only a couple of packages are exported. 
> Is there a reason why this list is so short?

Well, that's the API. What else would like to add?

Original comment by thomas.t...@gmail.com on 3 Mar 2011 at 8:10

• Changed state: Accepted

[GoogleCodeExporter]

> the bundle manifest originally provided
> by the H2 maintainers is sloppy at best

What else would you like me to change?

Original comment by thomas.t...@gmail.com on 3 Mar 2011 at 8:12

[GoogleCodeExporter]

>> the bundle manifest originally provided
>> by the H2 maintainers is sloppy at best

That was an exaggeration and I'm sorry for that:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=337106#c9

> What else would you like me to change?

It strikes me that the bundle version should make use of the qualifier segment. 
Here is a discussion that mentions this fourth version segment: 
http://blog.meschberger.ch/2009/10/on-version-numbers.html

Ideally the version qualifier expresses change in non-code artifacts such as 
the manifest itself, legal files, documentation and the like. Our (Buckminster) 
build generates this qualifier from the timestamp of latest change to any 
bundle artifact (taken from Subversion). If that's to hard to automate in your 
build system you should use the build ID or timestamp (although that may 
suggest internal changes that did not happen). For p2 (the successor of the 
Eclipse Update Manager) these qualifiers are important to be able to propose 
needed updates.

> The reason for "DynamicImport-Package: *" is that H2 optionally(!) 
> supports SLF4J, Lucene [...]

As these look like typical upstream dependencies you may be better off to 
import the respective packages explicitely but optionally. The OSGi Core 
specification explains this in section 3.6.3 (Optional Packages): 
http://www.osgi.org/download/r4v42/r4.core.pdf

> user defined triggers, functions, aggregate functions, stored procedures,
> table engines, file system implementations, and database event listeners.
> The class names of the user defined classes are persistent in some cases.

These look like downstream dependencies and DynamicImport-Package seems to be 
one of the few ways to deal with them. Personally I don't like it that much and 
I'm not sure about possible scalability issues. Architecture wise it would 
probably be better to require users to explicitely register their extensions, 
but that's a hard decision.

In Equinox OSGi I tend use "Eclipse-BuddyPolicy: Registered". Although 
http://www.eclipsezone.com/eclipse/forums/t90282.html suggests that 
Bundle-BuddyPolicy has made it into the spec, I could not find a mention of 
this header in R4.2 ;-(

Original comment by eike.ste...@googlemail.com on 4 Mar 2011 at 6:30

[GoogleCodeExporter]

>> only a couple of packages are exported. 
>> Is there a reason why this list is so short?
>
>Well, that's the API. What else would like to add?

I wasn't sure, the eclipse-packaged bundle had a longer list. But if that's the 
public API, that sounds like a good enough reason :)

Greg

Original comment by *gn...@b2international.com on 4 Mar 2011 at 8:17

[GoogleCodeExporter]

While we are discussing osgi bundles, it would be really awesome if a source 
bundle was also produced during the build. Simply jaring up the org subdir in 
src/main, and adding a manifest like this would allow developers using eclipse 
to see sources and javadoc in the editors. 

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: H2 Database Engine Sources
Bundle-SymbolicName: org.h2.source
Bundle-Vendor: H2 Group
Bundle-Version: 1.3.152
Eclipse-SourceBundle: org.h2;version="1.3.152"

Original comment by *gn...@b2international.com on 4 Mar 2011 at 8:29

[GoogleCodeExporter]

The next h2-*-sources.jar will have such a manifest file.

I will currently keep the "DynamicImport-Package: *" as is, but if required I 
can change it (but in this case it would be great if you could post the exact 
manifest file contents; I found out it's quite fragile - newlines need to be at 
the right place and so on). I would just like to avoid adding a bug.

Original comment by thomas.t...@gmail.com on 11 Mar 2011 at 11:53

[GoogleCodeExporter]

> if a source bundle was also produced

By the way: the javadoc and source bundles are already generated (since
quite a long time actually) and available in the Maven repository:
http://repo2.maven.org/maven2/com/h2database/h2/1.3.152/

Original comment by thomas.t...@gmail.com on 11 Mar 2011 at 12:05

[GoogleCodeExporter]

Should be fixed in version 1.3.153

Original comment by thomas.t...@gmail.com on 25 Mar 2011 at 7:23

• Changed state: Fixed