My understanding is that, as I explained in my earlier mail,
you don't need features at all.
If you have an "application bundle" and the xml repository, that should be
enough, you don't have to wrap them.
Could you please raise a JIRA and attach the artefacts needed to
"reproduce" the use case ? I.e. maybe a zip containing the xml repository
and the bundles, including the application bundle.
I'll investigate to make sure you can deploy it easily.
2015-11-30 11:39 GMT+01:00 David Leangen <apa...@leangen.net>:
>
> 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
>
>
>
