Issue 298 in protobuf: protobuf jar's manifest should include OSGi metadata
prot...@googlecode.com
Owner: liuj...@google.com
Labels: Type-Defect Priority-Medium
New issue 298 by neverov....@gmail.com: protobuf jar's manifest should
include OSGi metadata
http://code.google.com/p/protobuf/issues/detail?id=298
What steps will reproduce the problem?
1. build the jar
2. open it and look at META-INF/MANIFEST.MF
What is the expected output? What do you see instead?
- There should be OSGi R4.2 metadata present
What version of the product are you using? On what operating system?
- reproes on all
Please provide any additional information below.
- This is needed in order to be able to install and use protobuf jar inside
OSGi container
Ben Wright
manually build and bundle the protobuf jar as an OSGi library jar.
On May 27, 11:41 am, proto...@googlecode.com wrote:
> Status: New
> Owner: liuj...@google.com
> Labels: Type-Defect Priority-Medium
>
> New issue 298 by neverov....@gmail.com: protobuf jar's manifest should
prot...@googlecode.com
Status: NeedPatchFromUser
Comment #1 on issue 298 by liuj...@google.com: protobuf jar's manifest
should include OSGi metadata
http://code.google.com/p/protobuf/issues/detail?id=298
Hmm, I'm not familiar with OSGi. Would you please provide a patch for this?
prot...@googlecode.com
Comment #2 on issue 298 by neverov....@gmail.com: protobuf jar's manifest
http://code.google.com/p/protobuf/issues/detail?id=298
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.
prot...@googlecode.com
Comment #3 on issue 298 by neverov....@gmail.com: protobuf jar's manifest
http://code.google.com/p/protobuf/issues/detail?id=298
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"
Attachments:
osgi.patch 2.0 KB
prot...@googlecode.com
Comment #4 on issue 298 by sam.hend...@gmail.com: protobuf jar's manifest
http://code.google.com/p/protobuf/issues/detail?id=298
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.
prot...@googlecode.com
Comment #5 on issue 298 by neverov....@gmail.com: protobuf jar's manifest
http://code.google.com/p/protobuf/issues/detail?id=298
Well, in my project I also use Felix and I believe I got an error
with "2.4.2-pre".
I saw that recommendation in the book called OSGi in Action. Also at
http://www.osgi.org/javadoc/r4v43/org/osgi/framework/Version.html I can see:
"public Version(java.lang.String version)
Created a version identifier from the specified string.
Here is the grammar for version strings.
version ::= major('.'minor('.'micro('.'qualifier)?)?)?
major ::= digit+
minor ::= digit+
micro ::= digit+
qualifier ::= (alpha|digit|'_'|'-')+
digit ::= [0..9]
alpha ::= [a..zA..Z]
There must be no whitespace in version."
So, I guess "2.4.2.-pre" would qualify as well. But IMHO it looks
strange. :)
prot...@googlecode.com
Comment #6 on issue 298 by compuwar...@gmail.com: protobuf jar's manifest
http://code.google.com/p/protobuf/issues/detail?id=298
As a check against what other are doing... we use the following data in
meta-inf
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Protocol Buffers Library
Bundle-SymbolicName: com.google.protobuf
Bundle-Version: 2.4.1
Bundle-Vendor: Google
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Export-Package: com.google.protobuf
prot...@googlecode.com
Comment #7 on issue 298 by thomas.k...@googlemail.com: protobuf jar's
http://code.google.com/p/protobuf/issues/detail?id=298
To create an OSGI bundle apply the following changes to the pom.xml:
(Line 14):
<packaging>bundle</packaging>
instead of
<packaging>jar</packaging>
in <build><plugins> add
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<Export-Package>*</Export-Package>
</instructions>
</configuration>
</plugin>
That's about it.
prot...@googlecode.com
Comment #8 on issue 298 by cjdo...@gmail.com: protobuf jar's manifest
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.
prot...@googlecode.com
Comment #9 on issue 298 by cgrube...@gmail.com: protobuf jar's manifest
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.
Attachments:
fixpom.diff 3.3 KB
prot...@googlecode.com
Owner: xiaof...@google.com
Comment #10 on issue 298 by liuj...@google.com: protobuf jar's manifest
(No comment was entered for this change.)
prot...@googlecode.com
Comment #11 on issue 298 by cgrube...@gmail.com: protobuf jar's
Woops - better - updated plugin version for osgi generation.
Attachments:
osgi.patch 3.3 KB
prot...@googlecode.com
Comment #12 on issue 298 by cgrube...@gmail.com: protobuf jar's
Craaaap. Fixed typo in project url.
Attachments:
osgi.patch 3.3 KB
prot...@googlecode.com
prot...@googlecode.com
Comment #14 on issue 298 by matteo.c...@gmail.com: protobuf jar's manifest
It shouldn't be this difficult. maven-bundle-plugin can generate a proper
OSGi manifest, any reason why this is taking so long? :)
Thanks
prot...@googlecode.com
Comment #15 on issue 298 by xiaof...@google.com: protobuf jar's manifest
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.
prot...@googlecode.com
Comment #16 on issue 298 by matteo.c...@gmail.com: protobuf jar's manifest
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.apache.servicemix.bundles.protobuf-java
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.
prot...@googlecode.com
Comment #17 on issue 298 by cjdo...@gmail.com: protobuf jar's manifest
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.
prot...@googlecode.com
Comment #18 on issue 298 by rocketra...@gmail.com: protobuf jar's manifest
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.
prot...@googlecode.com
Comment #19 on issue 298 by cvgav...@gmail.com: protobuf jar's manifest
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 :(
prot...@googlecode.com
Comment #20 on issue 298 by m...@thebishops.org: protobuf jar's manifest
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.
prot...@googlecode.com
Comment #21 on issue 298 by xiaof...@google.com: protobuf jar's manifest
I have no idea of how widely OSGi is used in the open source community. Is
it the suggested way to add OSGi meta data to every Java jar?
prot...@googlecode.com
Comment #22 on issue 298 by matteo.c...@gmail.com: protobuf jar's manifest
This is the best way to add suport in my opinion since the manifest file
gets generated and there's no room for mistakes there ->
http://code.google.com/p/protobuf/issues/detail?id=298#c7
Thanks for looking into it.
prot...@googlecode.com
Comment #23 on issue 298 by cjdo...@gmail.com: protobuf jar's 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.
prot...@googlecode.com
Comment #24 on issue 298 by xiaof...@google.com: protobuf jar's manifest
OK, I'll patch the change suggested in comment #7 to the trunk soon. Thanks
for your info.
prot...@googlecode.com
Comment #25 on issue 298 by debroux....@gmail.com: protobuf jar's manifest
It could be good to have two different artifacts for the full-blown version
and the significantly smaller and leaner lite version... if it is possible
to distinguish, at runtime, between the full-blown version and the lite
version (using some combination of versioned package exports ?).
prot...@googlecode.com
Comment #26 on issue 298 by rocketra...@gmail.com: protobuf jar's manifest
If you have a lite and full jar, from an OSGi perspective, it is better
*not* to distinguish the package exports i.e. for the packages that
overlap, the package export spec should be exactly the same. The only
difference will be that the full jar will export extra packages.
That way users can decide (based on which packages they need to import)
which jar they need to use.
This approach also lends towards good code structure -- "full jar"
functionality will be isolated at the package level.
prot...@googlecode.com
Comment #27 on issue 298 by xiaof...@google.com: protobuf jar's manifest
Hi all,
I have prepared a change for code review. Please help review it at:
https://codereview.appspot.com/6745056/
If there are no problems, I will submit it to trunk tomorrow.
Thanks.
prot...@googlecode.com
Comment #28 on issue 298 by m...@thebishops.org: protobuf jar's manifest
I looked of the code review. Looks good. The <Export-Package> instruction
is unnecessary but does no harmgiven the classes are all in one package and
there are no "impl" elements in the package structure.
prot...@googlecode.com
Status: Fixed
Comment #29 on issue 298 by xiaof...@google.com: protobuf jar's manifest
Patch submitted to trunk. Thanks.
prot...@googlecode.com
Comment #30 on issue 298 by cvgav...@gmail.com: protobuf jar's manifest
which version will contain this fix ?
prot...@googlecode.com
Comment #31 on issue 298 by xiaof...@google.com: protobuf jar's manifest
Re: "which version will contain this fix ?" It will be included in the next
release 2.5.0
prot...@googlecode.com
Comment #32 on issue 298 by cvgav...@gmail.com: protobuf jar's manifest
could someone tell me when 2.5.0 will be released ?
prot...@googlecode.com
Comment #33 on issue 298 by xiaof...@google.com: protobuf jar's manifest
You can find 2.5.0rc1 tarballs in the download page.
prot...@googlecode.com
Comment #34 on issue 298 by cvgav...@gmail.com: protobuf jar's manifest
thanks. the problem is that I need it in the maven repo to convince Drools
team to upgrade to the new version.
prot...@googlecode.com
Comment #35 on issue 298 by xiaof...@google.com: protobuf jar's manifest
Our estimation of the release date is early next Q1. We may probably get it
out sooner if the release candidates are doing well.