Bug 52381 - Please add OSGi metadata
Please add OSGi metadata
Status: NEW
Product: Tomcat 7
Classification: Unclassified
Component: Packaging
trunk
PC Linux
: P2 enhancement with 2 votes (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2011-12-22 12:28 UTC by Alexander Kurtakov
Modified: 2012-03-22 13:18 UTC (History)
2 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Kurtakov 2011-12-22 12:28:15 UTC
As a downstream we(Fedora) modify a number of the Tomcat jars to add OSGi metadata in them. You can see them here http://pkgs.fedoraproject.org/gitweb/?p=tomcat.git;a=tree . But the process is really error prone and somethimes versions go out of sync. It would be really cool if this metadata is properly generated by the buildsystem.
Comment 1 Alexander Kurtakov 2011-12-22 12:40:36 UTC
The manifests used aren't good enough for inclusion but I'll try to come with something better after vacation.
Comment 2 Mark Thomas 2011-12-23 21:27:07 UTC
Not knowing much about OSGI, if you could provide suitable manifests that would be great. Once we have them, plugging them into the build is relatively simple.
Comment 3 Mark Thomas 2011-12-29 20:11:43 UTC
Marking as an enhancement.
Comment 4 pan4o 2012-01-05 12:45:51 UTC
This is a very important issue for us too, because of our Apache Karaf environment. See bugs 52318 and 52429
Comment 5 Violeta Georgieva 2012-01-12 21:49:43 UTC
Hello,

In Eclipse Virgo we add OSGi metadata using Bundlor. The process is pretty straightforward and we have projects that do that stuff. Unfortunately we do not add OSGi metadata for every Apache Tomcat release but only for those that we include in Eclipse Virgo.

The artifacts are available through EBR. Here they are:

http://ebr.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.catalina&version=7.0.23&searchType=bundlesByName&searchQuery=catalina

http://ebr.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.catalina.ha&version=7.0.23&searchType=bundlesByName&searchQuery=catalina

http://ebr.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.catalina.tribes&version=7.0.23&searchType=bundlesByName&searchQuery=catalina

http://ebr.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.coyote&version=7.0.23&searchType=bundlesByName&searchQuery=coyote

http://ebr.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.jasper&version=7.0.23&searchType=bundlesByName&searchQuery=jasper

http://ebr.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.el&version=7.0.23&searchType=bundlesBySymbolicName&searchQuery=org.apache.el

http://ebr.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.juli.extras&version=7.0.23&searchType=bundlesBySymbolicName&searchQuery=juli

http://ebr.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.tomcat.api&version=7.0.23&searchType=bundlesBySymbolicName&searchQuery=org.apache.tomcat

http://ebr.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.tomcat.util&version=7.0.23&searchType=bundlesBySymbolicName&searchQuery=org.apache.tomcat

Best Regards
Violeta Georgieva
Comment 6 Glyn Normington 2012-02-17 11:17:56 UTC
If OSGi metadata is added, I suggest also adding a basic test to Tomcat's build to check that the Tomcat bundle resolve. (I created a similar test for Spring and I recommend the approach of using Pax Exam - see https://jira.springsource.org/browse/SPR-8791).
Comment 7 Alexander Kurtakov 2012-02-17 11:21:59 UTC
In order to avoid cyclic dependencies and yes servlet.jar is used in too many places so having dependencies to build its osgi metadata will be a big PITA I think that the simplest approach for building would be best - no bundlor, no pam-exam and etc.The manifest is just few key/value pairs in the manifest after all. This doesn't mean that tests/verification/etc. targets should not be added but the buildsystem itself should work without them.
Comment 8 Mark Thomas 2012-03-20 22:36:51 UTC
As far as I am aware, there is very little OSGI expertise amongst the Tomcat devs. What is really required for this enhancement is either:
- a patch that generates the necessary meta data as part of the build script; or
- a simple (no long words please) explanation of exactly what needs to be included in the meta data so someone with no OSGI understanding can generate it.
Comment 9 pan4o 2012-03-21 06:18:23 UTC
Very important for each bundle are the imports and exports sections in the MANIFEST file. We do this so:

<plugin>
	<groupId>org.apache.felix</groupId>
	<artifactId>maven-bundle-plugin</artifactId>
	<version>2.3.4</version>
	<extensions>true</extensions>
	<configuration>
        <instructions>
		<Require-Bundle />
		<Export-Package>our.package;version="${pom.version}"
                </Export-Package>
		<Import-Package>!our.package,org.springframework.aop;version="${spring.version}",org.springframework.aop.framework;version="${spring.version}",org.aopalliance.aop, *               </Import-Package>
		<Embed-Dependency>*;artifactId=postgresql,*;artifactId=tomcat-jdbc</Embed-Dependency>
	</instructions>
	</configuration>
</plugin>

Embed-Dependency because postgresql and tomcat-jdbs are not correct bundles.
Comment 10 pan4o 2012-03-22 12:51:21 UTC
if you need a more detailed POM ... i will submit a complete one :)
Comment 11 Mark Thomas 2012-03-22 12:54:10 UTC
The POM is no use since Tomcat is not built with Maven. What is required is details of what needs to go into the manifests.
Comment 12 pan4o 2012-03-22 13:18:20 UTC
All dependencies (imports) you need in a project, should be in Import-Package:
All packages you want to expose (make them public), should be in Export-Package: 

In the OSGI way you can expose throgh the Export-Package only that what you want to be public. In the sample MANIFEST we are exposing only our interfaces without exposing the implementation. Sooo no external package running in Karaf can access the implementation.


Sample MANIFEST:

Manifest-Version: 1.0
Export-Package: our.package;version="0.0.1.SNAPSHOT"
Bundle-ClassPath: .,postgresql-9.0-801.jdbc4.jar,tomcat-jdbc-7.0.22.jar
Built-By: hudson
Tool: Bnd-1.15.0
Bundle-Name: our.package
Created-By: Apache Maven Bundle Plugin
Build-Jdk: 1.6.0_21
Bundle-Version: 0.0.1.SNAPSHOT
Bnd-LastModified: 1330958118424
Bundle-ManifestVersion: 2
Embed-Dependency: *;artifactId=postgresql,*;artifactId=tomcat-jdbc
Import-Package: org.springframework.jdbc.core.namedparam;version="[3
 .0,4)",org.springframework.jdbc.core.simple;version="[3.0,4)",org.spr
 ingframework.jdbc.datasource;version="[3.0,4)",org.springframework.tr
 ansaction.annotation;version="[3.0,4)",org.w3c.dom,org.xml.sax
Bundle-SymbolicName: our.package