Ok. I'll try to look into it later this week (probably over the weekend).
First, I'll try to identify what exactly this metadata should be to make it work with my project. Then, I'll try to figure out how to make Maven generate it properly.
Couldn't hold myself from looking into this :) Please find the first version of the patch attached (sorry if it's not in accepted format - this is the first time I try to contribute).
There is one concern though. I've noticed that you use "2.4.2-pre" as an intermediate version number. As far as I know, OSGi spec requires all components to be separated by dots, so "2.4.2.pre" would be correct. Without this change, installing such a bundle (jar) into OSGi container will fail. So, I can see two approaches we can take: 1) Name intermediate versions as OSGi requires (using dots) 2) Create a separate property like "osgi.version"
I would vote for the approach 1), since it avoids duplication.
To my best knowledge, the generated manifest should look like this (feel free to suggest if something looks wrong):
Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: ann Build-Jdk: 1.6.0_21 Bundle-ManifestVersion: 2 Bundle-SymbolicName: com.google.protobuf Bundle-Version: 2.4.2.pre Bundle-Name: Protocol Buffer Java API Bundle-Description: Protocol Buffers are a way of encoding structured data in an efficient yet extensible format. Bundle-Vendor: googlecode.com Bundle-DocURL: http://code.google.com/p/protobuf Bundle-Category: newtwork, library Bundle-License: http://www.opensource.org/licenses/bsd-license.php Bundle-RequiredExecutionEnvironment: J2SE-1.5 Export-Package: com.google.protobuf;version="2.4.2.pre"
My team has been creating and using snapshot bundles in karaf/Felix OSGi containers for a few months so I don't think it's a hard requirement that bundles have only 3 dot version #s.
The advantage of comment #7's approach is that OSGi vs. Maven version
number syntax is automatically handled by the plugin. I strongly endorse
that approach. But the patch from comment #3 is pretty good too.
Here's a patch to the pom, adapted from Guice's info, that doesn't require
a packaging type change, and includes appropriate copyright info, is
compatible with the M2E (maven eclipse integration).
It also fixes the maven version number, setting it to the recommended
2.4.2-SNAPSHOT (-pre is treated as a final release version called -pre,
whereas SNAPSHOT is treated as a volatile in-development version). As
mentioned above in comment #7, felix will take care of all the important
metadata translations.
Sorry, I didn't have enough time to work on protobuf opensource release for
the last few weeks.
As to the OSGi manifest, the change seems to be trivial, but it doesn't
seem right to me that we should change protobuf to make it conform to the
specification of a certain container.
OSGi is the defacto standard to build modular java applications. Many
groups have done the wrapping themselves (see
http://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.a... for instance) and there are now different osgfied snapshot of protobuf all
over the place, which is very confusing and not right in any way.
Re: "it doesn't seem right to me that we should change protobuf to make it
conform to the specification of a certain container." All Apache jars and
many, many other popular jars (Spring, Guice, etc) have added OSGi headers,
It's a trivial way to be a good citizen in the open source community.
"it doesn't seem right to me that we should change protobuf to make it
conform to the specification of a certain container." --> In addition to
the other comments, I might also note that, to be completey accurate, you
aren't really *changing* protobuf as such. Rather you are *adding* support
for many containers and applications that use OSGi meta-data. And the good
part is that this addition is trivial and completely compatible with
non-OSGi containers and applications.
I would like to use protobuf (in its latest version) in my equinox project
too... Today I had to use a old version that was wrapped by spring source :(
Protobuf is about enabling optimal data transfer between devices and
servers. OSGi is about java software on mobile devices as well as other
platforms. Seems only natural that the java version of protobuf has these
headers in its manifest.
Re: "Is it the suggested way to add OSGi meta data to every Java jar?" Yes.
Increased modularity is Java's future, and OSGi is the dominant mechanism
for modularity today. It's trivial to support it and it's very popular.
Adding these few header values can increase protobuf's reach with almost no
work.
