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.
The manifests used aren't good enough for inclusion but I'll try to come with something better after vacation.
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.
Marking as an enhancement.
This is a very important issue for us too, because of our Apache Karaf environment. See bugs 52318 and 52429
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
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).
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.
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.
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.
if you need a more detailed POM ... i will submit a complete one :)
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.
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
Created attachment 35625 [details] Attempt to add OSGi metadata Back on 2011-09-06 Roland Grunberg added the OSGi manifests that are used in the Fedora-generated Tomcat JARs today (see http://pkgs.fedoraproject.org/cgit/rpms/tomcat.git/tree/ for more details). I see now that those are outdated (old spec versions and such) so I'll update them at some point. Using those as an example of what's required, I updated the templates found in res/META-INF/*.manifest to add the OSGi metadata and added a few new manifests that include OSGi metadata in the manner discussed in previous comments (not using bundlor, or anything special). Hopefully this is correct... Disclaimer: I don't know much about OSGi, have no way to test this, and it seems that nobody is using the Fedora ones because there is incorrect information in them, so they may be wrong.
(In reply to Coty Sutherland from comment #13) > Created attachment 35625 [details] > Attempt to add OSGi metadata > > Back on 2011-09-06 Roland Grunberg added the OSGi manifests that are used in > the Fedora-generated Tomcat JARs today (see > http://pkgs.fedoraproject.org/cgit/rpms/tomcat.git/tree/ for more details). > I see now that those are outdated (old spec versions and such) so I'll > update them at some point. Using those as an example of what's required, I > updated the templates found in res/META-INF/*.manifest to add the OSGi > metadata and added a few new manifests that include OSGi metadata in the > manner discussed in previous comments (not using bundlor, or anything > special). Hopefully this is correct... > > Disclaimer: I don't know much about OSGi, have no way to test this, and it > seems that nobody is using the Fedora ones because there is incorrect > information in them, so they may be wrong. Hi Coty, I'm can help with OSGi (I'm committer in Gemini Web - OSGi web container reference implementation). Tomcat version 8.5.16 is the latest version that I have with OSGi meta data. However every project has its own understanding what should be included in the OSGi meta data. Regards, Violeta
Any thoughts on the patch? It's a rough draft and I should replace all the hard coded spec version info with dynamic stuff, but as far as using these manifests as a template to fill in other info, does that look OK to anyone/everyone? I don't see any other easy alternative to generate this info except maybe Apache Ivy, which has an experimental OSGi bundle thingy.
I have a few comments but keep in mind my minimal OSGI knowledge: - I see placeholders %bundleProvider, %bundleName etc. nut nothing to populate them - The execution environments look wrong given the java version they are compiled for - The imports for jasper.jar look to be too wide. org.apache.commons.el, for example, is an old UEL implementation that Tomcat shouldn't (and doesn't as far as I know) depend on - version numbers need updating for Tomcat 9 (Servlet 4.0) I also compared the the patch to the manifests provided in the latest Eclipse Virgo release. There are a lot of differences. I'm not sure how significant they are.
I'm making some progress integrating bnd into the trunk build via the Ant plug-in. I've got it to the point where JARs with OSGI manifests are created. The next steps are: a) add property files for each JAR so we can tailor each OSGI manifest appropriately b) get the manifests reviewed c) modify the build process so JARs are created with the OSGI manifest I should be in a position to commit something later today
It took a little longer than I expected but this is now implemented for 9.0.x