Hi,
Wow! This list is really active. :-D
I think Christian explains it quite well. Allow me to add in more concrete,
low-level details to complement this explanation.
First of all, I have a “bootstrapping" bundle, with no dependencies on any of
my other bundles, but some dependencies on, for example, Karaf. This bundle
handles the deployment functions described below. This bundle is set up as a
boot feature in Karaf. Along with the things being discussed below, it will
allow me to accomplish my objective.
In my development environment, I have several bndtools workspaces in Eclipse. I
believe this is quite typical in a bndtools environment. Each workspace usually
(but not always) has an “application bundle”, whose purpose is to pull in all
the requirements for the “application” (what is, I believe, essentially
homologous to a Karaf feature, minus the configuration).
In my enRoute application bundles, I created a KarafFeature annotation like
this:
@ProvideCapability(
ns = "karaf.identity",
value = "type=karaf.feature"
)
@Retention(RetentionPolicy.CLASS)
public @interface KarafFeature
{
String name();
String description();
String version();
}
Used on my “application service” class:
@RequireTestFoo
@RequireTestBar
@KarafFeature(
name = “feature-name",
description = “Short description of feature",
version = “1.0.0"
)
public class TestInstallation
{
}
The capability output via bnd to the Manifest:
Provide-Capability: karaf.identity;description=“Short description of
feature";version:Version=“1.0.0";karaf.identity=feature-name;type="karaf.feature"
[**Note:
> The requirement for a feature is already formalized in karaf:
>
> osgi.identity;osgi.identity=feature-name;type=karaf.feature;version="version-range"
I tried this, but apparently bnd does not like it, so in my implementation I
changed it from “osgi.identity” to “karaf.identity”. I don’t know if this is a
bug in bnd, or if Karaf is using osgi.identity for something it should not. :-)
]
bnd provides a “release” function, which creates an OBR with all the bundles
from the workspace. This can be done via Eclipse or as a headless build from
gradle. Thus, for each workspace, on the CI server, when a build is successful,
the result is an OBR repo as the output.
I currently use Bamboo for our CI server. It has a “deployment” function, which
we use to push the released OBR repos to a repository server. The developer’s
job ends here, as this is also the handoff point to the deployer. I believe
that the roles should be separated. From a business perspective, if we required
that a deployer has the same level of expertise as a developer, things would be
very expensive. ;-)
In crappy ASCII art, it would be:
+-----+ +--------+
| Dev |——>[OBR Repos]<——| Deploy |
+-----+ +--------+
Once in Karaf, since I want to have a local cache of my OBR repositories in
order to completely decouple the runtime system from any development or
deployment system, I (programmatically) have Cave populate corresponding local
caches. So my deployment bundle will first obtain and cache the OBR
repositories (one for each bnd workspace) and cache it locally via Cave.
The deployer, when initiating a deployment, will therefore pull the released
OBR repos via Cave. I then parse the respository.xml file to find any
capabilities in the karaf.identity namespace, and pull in any information I
need to create a Karaf feature on the fly. (Probably you can imagine this, but
I can show you the fairly trivial code if necessary.)
I have an XML parser that will extract the information necessary to generate
the Karaf feature from the capabilities in the application bundle in each Repo.
However, if I could input either the bundle or the repo and let Karaf extract
the feature information, that would be even better.
Based on the above, I could easily create Karaf commands to allow the deployer
to pull in the latest versions (deployed as OBR repos) and deploy as necessary
as features, which would be generated on the fly from the included capabilities.
I believe that this would be a very nice, easy, and natural way to “integrate”
an eRoute (bnd) development environment with the Karaf runtime. Developers
continue to work as usual, in theory without having to worry about which
runtime is being used, while the deployer can do her job very easily from start
to finish from the Karaf command line without having to stop the system, change
configuration, or even call on developers (unless something blows up).
Please let me know if I can provide any further info. :-)
Cheers,
=David
