I don't know if it is a big deal but here's an example of a current project
I work on. In a static environment much of that could be generated I'd
think. At least the parts that are straight bundles. And really, in a
static include the feature tags themselves could be pulled in and expanded
to bundle statements as well since in the end we aren't leveraging features
from an installed karaf anymore. Those features/profiles would act more
like recipes for the creation of the karaf-boot itself.
If one went with a convention over configuration approach as well then one
could always specify a configuration.cfg in the root of the resources
directory and have that automatically converted into a cfg file in the
bundle that matched the PID. The whole configfile section could be
eliminated then. If a configuration.cfg file is found in the resource
directory then the static compilation could turn that into the correct
PID.cfg and install it during bundle creation into the etc directory for
boot up.
None of that is huge deal but it would make life a bit more convenient and
since one is now working from a static point of view it seems it would be
much easier to accomplish.
<?xml version="1.0" encoding="UTF-8"?>
<features name="${project.artifactId}-${project.version}" xmlns="
http://karaf.apache.org/xmlns/features/v1.0.0"; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="
http://karaf.apache.org/xmlns/features/v1.0.0
http://karaf.apache.org/xmlns/features/v1.0.0";>
<!-- The repositories of the Middleware -->
<repository>mvn:org.apache.camel.karaf/apache-camel/${camel-version}/xml/features</repository>
<repository>mvn:org.apache.cxf.karaf/apache-cxf/${cxf-version}/xml/features</repository>
<feature name="payment-hub-gateway-prerequisites"
version="${project.version}">
<configfile finalname="/etc/com.foo.orchestration.cfg"
override="false">mvn:com.foo/orchestration/${project.version}/cfg/configuration</configfile>
<configfile finalname="/etc/com.foo.connector.litle.cfg"
override="false">mvn:com.foo/connector.litle/${project.version}/cfg/configuration</configfile>
<configfile finalname="/etc/com.foo.gateway.cfg"
override="false">mvn:com.foo/gateway/${project.version}/cfg/configuration</configfile>
<configfile finalname="/etc/com.foo.batch.cfg"
override="false">mvn:com.foo/batch/${project.version}/cfg/configuration</configfile>
<configfile finalname="/etc/com.foo.bar.cfg"
override="false">mvn:com.foo/bar/${project.version}/cfg/configuration</configfile>
<configfile finalname="/etc/com.foo.services.cfg"
override="false">mvn:com.foo/services/${project.version}/cfg/configuration</configfile>
<feature>camel-core</feature>
<feature>camel-blueprint</feature>
<feature>camel-cxf</feature>
<feature>camel-jackson</feature>
<feature>camel-xmljson</feature>
<feature>camel-beanio</feature>
<feature>camel-xstream</feature>
<feature>camel-dozer</feature>
<feature>camel-velocity</feature>
<feature>cxf-ws-security</feature>
<bundle>mvn:org.apache.aries.blueprint/org.apache.aries.blueprint.core.compatibility/1.0.0</bundle>
<bundle>mvn:org.codehaus.jettison/jettison/${jettison-version}</bundle>
<bundle>mvn:org.apache.commons/commons-lang3/${commons-lang3-version}</bundle>
<bundle>wrap:mvn:org.apache.httpcomponents/httpcore/${httpcore-version}</bundle>
<bundle>wrap:mvn:org.apache.httpcomponents/httpclient/${httpclient-version}</bundle>
<bundle>wrap:mvn:commons-io/commons-io/${commons-io-version}</bundle>
</feature>
<feature name="foo-hub-gateway" version="${project.version}">
<bundle>mvn:com.foo/models/${project.version}</bundle>
etc. etc.
On Mon, Apr 18, 2016 at 2:29 AM, Christian Schneider <
ch...@die-schneider.net> wrote:
> I am not very familiar with the concept of profiles till now. Guillaume
> explained it a bit to me but honestly I hope we do not need it too often.
> An OSGi application should be mainly built out of bundles and profiles
> concentrate more on the non OSGi static files in karaf.
>
> The main part of the packaging in karaf boot is to resolve features at
> build time. It uses the static profile but nothing else from the profiles
> concept. This part already works. I have created such a packaging for the
> tasklist-ds example:
> https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-ds/app
>
> The second part. The karaf boot development model is still in the making
> but you can already use the packaging if you want.
>
> About features and poms you are right. You have to maintain two sets of
> dependencies but this is just a result of the fact that OSGi resolves
> differently from maven. So this never will completely go away. What we
> could do with a pom is create an obr repository. This could then be used to
> back a feature repo. So currently in a feature we have to list all the
> bundles, with a backing obr repo we could instead only list some
> requirements (like top level bundles) and resolve the rest.
>
> I have prototyped such a packaging using bndtools as it already has the
> OBR resolving:
> https://github.com/cschneider/bndtools-tutorials/tree/master/tasklist-ds
> The creation of the repository went quite smoothly as eclipse m2e provides
> nice tooling to define the pom and the necessary excludes.
> Defining the requirements in bndtools also works really nicely as they got
> a good UI for it.
>
> Unfortunately bndtools does not know about features. So while this
> approach is better than defining each single bundle of an application it is
> not really better than the karaf approach were you define most of your deps
> as features. So this would only be really useable once we have both
> features and a backing obr repo.
>
> Another thing that I found bndtools is lacking is all the preparation
> karaf already has for some of the more complicated features like
> tansactions and cxf. There it is not enough to just install bundles.
> You also have to fiddle with the boot path for transactions and some java
> se spec nightmares in the case of cxf. So these are the regions where karaf
> really helps.
>
> Christian
>
> On 18.04.2016 07:24, Brad Johnson wrote:
>
>> Christian,
>>
>> I just re-read your section on the static profiles. That makes sense. I
>> could see this becoming like puppet/chef sort of recipes or even like the
>> way Docker allows building up of images. Not that I know those that well.
>> I use features all the time of course but see huge advantage to making that
>> a bundle time set of static steps instead of the current runtime usage.
>> Not that the current use is bad, mind you, its context is different and
>> slimming down the karaf core by eliminating that management overhead would
>> be good for something like karaf-boot. In the current monolithic
>> enterprise environment it makes sense to have stacks of features available
>> to load when necessary. The static mechanism would get rid of that. But it
>> would also permit building up a centralized registry or library of features
>> that one could leverage by adding into a boot recipe of some sort. Maybe
>> we'd get the quick flexibility for creating projects that archetypes always
>> seemed to promise but never quit seemed to manage.
>>
>> One item that has always bothered me about features is they are
>> orthogonal to but replicate much of what goes into a POM. One ends up
>> with two sets of dependency management mechanisms that have never really
>> dovetailed. It would be nice if we had a Maven plugin that could look at
>> the dependencies in a POM and create a static feature profile or at least
>> give a good guess at what they should be while allowing for some tweaking.
>> Perhaps since the karaf-boot environment is static and doesn't rely on or
>> expect another environment to provide dependencies that would be easier to
>> accomplish.
>>
>> Funny how Moore's law took a sideways turn on us. Now we don't have the
>> ever increasing clock speed but we have cores coming out our ears and RAM
>> and disk space in abundance. A little fatness in our deployments is an
>> acceptable trade off now.
>>
>> Brad
>>
>>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
