It is already there. Give this example a spin:
https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-ds/app
Should be quite easy to adapt this to your own project.
Christian
On 18.04.2016 18:19, Brad Johnson wrote:
Sounds pretty spectacular. Can't wait to see it.
Brad
On Mon, Apr 18, 2016 at 11:13 AM, Guillaume Nodet <[email protected]
<mailto:[email protected]>> wrote:
2016-04-18 18:02 GMT+02:00 Brad Johnson
<[email protected] <mailto:[email protected]>>:
Jean-Baptiste,
So would something like a camel-core feature then be converted
into a static bundle with all its dependencies for bootstrap?
It seems that what one could do is define the features and the
read the features into a set at bundle time to eliminate any
overlap and then create the list of required
mvn:group/artifact statements in the new bundle.
Well, that's actually what the karaf plugin does when generating
the assembly.
Though it does the same thing than the OSGi resolver would do at
runtime, and handles additional things such as configuration,
start levels, libraries, etc...
But that also seems a prime candidate for leveraging Maven to
create that same thing. It has all the information required to
create that set of required bundles for bootstrap sans
features. But karaf would have to be made aware of them
somehow. Would these be specified in the startup.properties
and stored in the lib?
Sorry, I should probably just wait and see as I imagine it
gets a bit irritating to go over stuff you've already thought
out. I'm pretty stoked about the possibility though so my mind
naturally races on to how I'd like to see it work and how it
could make my life easier.
Brad
On Mon, Apr 18, 2016 at 10:52 AM, Jean-Baptiste Onofré
<[email protected] <mailto:[email protected]>> wrote:
Starting from features, you can create a full static
custom distribution, not actually really using features
but startup bundles.
Regards
JB
On 04/18/2016 05:47 PM, Brad Johnson wrote:
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
<[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> 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 wouldkie-aries-blueprint
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
--
Jean-Baptiste Onofré
[email protected] <mailto:[email protected]>
http://blog.nanthrax.net
Talend - http://www.talend.com
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: [email protected] <mailto:[email protected]>
Web: http://fusesource.com <http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
