Sounds pretty spectacular. Can't wait to see it. Brad
On Mon, Apr 18, 2016 at 11:13 AM, Guillaume Nodet <[email protected]> wrote: > > > 2016-04-18 18:02 GMT+02:00 Brad Johnson <[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]> >> 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]>> 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 >>>> >>>> >>>> >>> -- >>> Jean-Baptiste Onofré >>> [email protected] >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> >> >> > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Red Hat, Open Source Integration > > Email: [email protected] > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > >
