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
