search

jasonjack2015 / protobuf

Automatically exported from code.google.com/p/protobuf
Other
0 stars 0 forks source link

protobuf jar's manifest should include OSGi metadata #298

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
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

Original issue reported on code.google.com by neverov....@gmail.com on 27 May 2011 at 3:40

GoogleCodeExporter commented 9 years ago 
Hmm, I'm not familiar with OSGi. Would you please provide a patch for this?

Original comment by liujisi@google.com on 30 May 2011 at 5:30

GoogleCodeExporter commented 9 years ago 
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.

Original comment by neverov....@gmail.com on 30 May 2011 at 8:27

GoogleCodeExporter commented 9 years ago 
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"

Original comment by neverov....@gmail.com on 30 May 2011 at 2:30

Attachments:

GoogleCodeExporter commented 9 years ago 
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.

Original comment by sam.hend...@gmail.com on 30 May 2011 at 6:59

GoogleCodeExporter commented 9 years ago 
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. :)

Original comment by neverov....@gmail.com on 30 May 2011 at 7:16

GoogleCodeExporter commented 9 years ago 
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

Original comment by compuwar...@gmail.com on 31 May 2011 at 9:12

GoogleCodeExporter commented 9 years ago 
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.

Original comment by thomas.k...@gmail.com on 30 Aug 2011 at 1:03

GoogleCodeExporter commented 9 years ago 
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.

Original comment by cjdo...@gmail.com on 17 May 2012 at 3:56

GoogleCodeExporter commented 9 years ago 
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.

Original comment by cgruber@google.com on 9 Aug 2012 at 12:15

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by liujisi@google.com on 9 Aug 2012 at 3:34

GoogleCodeExporter commented 9 years ago 
Woops - better - updated plugin version for osgi generation.

Original comment by cgruber@google.com on 9 Aug 2012 at 7:05

Attachments:

GoogleCodeExporter commented 9 years ago 
Craaaap.  Fixed typo in project url.

Original comment by cgruber@google.com on 9 Aug 2012 at 7:06

Attachments:

GoogleCodeExporter commented 9 years ago 
Any status on this issue?

Original comment by m...@thebishops.org on 3 Oct 2012 at 8:42

GoogleCodeExporter commented 9 years ago 
It shouldn't be this difficult. maven-bundle-plugin can generate a proper OSGi 
manifest, any reason why this is taking so long? :)
Thanks

Original comment by matteo.c...@gmail.com on 22 Oct 2012 at 9:32

GoogleCodeExporter commented 9 years ago 
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.

Original comment by xiaof...@google.com on 22 Oct 2012 at 10:33

GoogleCodeExporter commented 9 years ago 
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.servi
cemix.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.

Original comment by matteo.c...@gmail.com on 22 Oct 2012 at 10:39

GoogleCodeExporter commented 9 years ago 
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.

Original comment by cjdo...@gmail.com on 22 Oct 2012 at 12:25

GoogleCodeExporter commented 9 years ago 
"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.

Original comment by rocketra...@gmail.com on 22 Oct 2012 at 1:15

GoogleCodeExporter commented 9 years ago 
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 :(

Original comment by cvgav...@gmail.com on 22 Oct 2012 at 1:54

GoogleCodeExporter commented 9 years ago 
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.

Original comment by m...@thebishops.org on 22 Oct 2012 at 3:07

GoogleCodeExporter commented 9 years ago 
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?

Original comment by xiaof...@google.com on 22 Oct 2012 at 3:49

GoogleCodeExporter commented 9 years ago 
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.

Original comment by matteo.c...@gmail.com on 22 Oct 2012 at 3:52

GoogleCodeExporter commented 9 years ago 
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.

Original comment by cjdo...@gmail.com on 22 Oct 2012 at 3:54

GoogleCodeExporter commented 9 years ago 
OK, I'll patch the change suggested in comment #7 to the trunk soon. Thanks for 
your info.

Original comment by xiaof...@google.com on 22 Oct 2012 at 4:14

GoogleCodeExporter commented 9 years ago 
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 ?).

Original comment by debroux....@gmail.com on 22 Oct 2012 at 4:48

GoogleCodeExporter commented 9 years ago 
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.

Original comment by rocketra...@gmail.com on 22 Oct 2012 at 4:57

GoogleCodeExporter commented 9 years ago 
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.

Original comment by xiaof...@google.com on 23 Oct 2012 at 8:38

GoogleCodeExporter commented 9 years ago 
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.

Original comment by m...@thebishops.org on 25 Oct 2012 at 12:57

GoogleCodeExporter commented 9 years ago 
Patch submitted to trunk. Thanks.

Original comment by xiaof...@google.com on 25 Oct 2012 at 6:23

GoogleCodeExporter commented 9 years ago 
which version will contain this fix ?

Original comment by cvgav...@gmail.com on 26 Oct 2012 at 4:58

GoogleCodeExporter commented 9 years ago 
Re: "which version will contain this fix ?" It will be included in the next 
release 2.5.0

Original comment by xiaof...@google.com on 29 Oct 2012 at 2:42

GoogleCodeExporter commented 9 years ago 
could someone tell me when 2.5.0 will be released ?

Original comment by cvgav...@gmail.com on 10 Dec 2012 at 7:05

GoogleCodeExporter commented 9 years ago 
You can find 2.5.0rc1 tarballs in the download page.

Original comment by xiaof...@google.com on 10 Dec 2012 at 7:06

GoogleCodeExporter commented 9 years ago 
thanks. the problem is that I need it in the maven repo to convince Drools team 
to upgrade to the new version.

Original comment by cvgav...@gmail.com on 10 Dec 2012 at 8:11

GoogleCodeExporter commented 9 years ago 
Our estimation of the release date is early next Q1. We may probably get it out 
sooner if the release candidates are doing well.

Original comment by xiaof...@google.com on 10 Dec 2012 at 8:49