Hi David,
my comments inline:
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.
We have the features maven plugin:
http://karaf.apache.org/manual/2.1.99-SNAPSHOT/developers-guide/features-maven-plugin.html
Using the features plugin, you can:
- features:generate-features-xml to generate the features XML
- features:add-features-to-repo which reads a features descriptor and
resolves artifacts to the local repo
FYI, we raised a JIRA to rename this maven plugin with a more generic
name: karaf.
The purpose is to provide new goals such as karaf:branding, karaf:run,
karaf:distribution, etc.
Of course, the existing goals will still exist:
karaf:generate-features-xml, karaf:add-features-to-repo.
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.
Agree, it's in the plan of the "new" generic karaf maven plugin:
- karaf:kar goal will take just a features descriptor (and eventually
some resources) to create the kar by packaging the features description
plus the bundles set
I raised a JIRA about that: KARAF-401.
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.
Yeah, as I said before, the kar goal could contains an instructions
(with includes/excludes tags) to embed resources into the generated kar
archive.
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.
Agree. I'm working about this.
The first step is to rename the features maven plugin into karaf maven
plugin to avoid to lost the users with several plugin name.
On the karaf maven plugin, the dist goal will create and package a
custom karaf container.
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.
We added the obr resolver in a feature.
If we package an OBR repository.xml in a feature, I could be append to
the Karaf instance OBR.
From my point of view, the OBR should be manage:
- by the Karaf instance itself
- by the provisioning tool
As we can consider the feature as a provisioning tool, it makes sense
that it can provide an OBR repository.xml.
Regards
JB
----
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
