Not sure if this idea makes much sense but.... it seems like a lot of the nuisance of using other peoples non-osgi jars is setting up all the little maven projects to bundleize them. If we start thinking about .kar files as a primary distribution mechanism maybe it would make sense to include the BND instructions in the configuration that assembles the .kar file so that non-osgi jars are bundleized as they get put in the .kar??
thanks david jencks On Jan 17, 2011, at 3:08 PM, David Jencks wrote: > Geronimo has had something similar to karaf features (.car files) for a long > time and I think some of the geronimo capabilities and plugin capabilities > would be very useful for karaf features. I'd like to start getting geronimo > to use more karaf capabilities so this seems like a good time to talk about > what to do. > > I should warn everyone that I'm not 100% familiar with features so it's quite > possible something I'm suggesting is already implemented or there's an > obvious reason it's inappropriate. Anyway here's what I have in mind: > > 1. maven-generated features.xml and maven feature packaging type. > Geronimo has some code that basically generates a features.xml that includes > the (appropriately scoped) pom dependencies and transitive dependencies, > stopping when a dependency is a feature. It even works with maven 3 :-) > (AFAICT the current generate-features-xml mojo does not). I haven't been > able to figure out what the current geronimo-feature-xml mojo tries to do but > it appears to be something else. So, the output from such a maven project > would be a features.xml file with a single feature including all the > transitive dependencies. This is a totally non-code project. A feature > maven packaging type would then deploy this as the sole generated artifact > for this project. Then you can refer to this project as a dependency and it > all fits into the maven infrastructure. > > 2. .kar files > I just found out about .kar files today. IIUC this is a jar file that > contains a feature.xml and the bundle dependencies listed in the feature.xml. > I think an additional mojo and packaging type that generates the feature.xml > as in (1) and then packages it and the bundles listed into an archive would > be a good idea. > > 3. resources in .kar files > Geronimo .car files can include resources that get unpacked on installation > into the server directory structure. While normally osgi bundles are supposed > to look for their data in their own osgi-managed data area, sometimes you > need something that the user can find :-) and it really belongs in a well > known location not associated with a particular bundle. In particular, in > geronimo we use this idea in server assembly. We have a .car file that has > the basic directory structure of a server and the startup jars packed as > resources. When assembling a server, we start with this .car file and unpack > the server structure out of it. > > 4. server assembly > (cf. KARAF-56) Karaf really needs a really simple way to assemble a custom > server using maven. Based on geronimo's experience, one way to do this would > be using a maven plugin that installed features and .kar files, using the > resource-in-kar idea from (3). You'd use a server-assembly packaging and > list all the features and kar files you want as dependencies, and the plugin > would install them and pack up the result. > > > Comments > > When assembling an osgi server, there's a battle between osgi/obr "I need > these packages/services" and maven/file-system/require-bundle "I want this > artifact". When a feature lists an artifact to install, its definitely on > the "this artifact" side of the line. What do you do when you get to > something you need but don't want to include in the feature? you can either > specify the external requirements as Import-Package and some kind of > require-service specifications or specify e.g. other features whose bundles > provide the requirements. Geronimo has used something similar to the > "specify other features" approach. Aries EBAs specify osgi package > requirements. If you want to assemble a server with the minimum input > information, relying on feature dependencies is very simple. However it > makes it harder to use alternate sources of packages and services. One idea > I had was to associate an OBR repository.xml with each feature that includes > the OBR info for the bundles in the feature. Then you can create a "virtual" > OBR from a set of features by including all the repository.xmls from the > features. If a feature specifies its external requirements both as osgi > requirements and as feature dependencies, an installer/assembler could check > if each feature dependency is needed to satisfy the osgi dependencies before > installing it. > > > ---- > > I'd really appreciate comments on these ideas. I'm going to start seeing if > I can munge the geronimo code to do some of this either in a karaf sandbox or > in git. Having some code to try out may be a lot clearer than my sometimes > convoluted explanations... > > thanks > david jencks
