<feature prerequisite="true" dependency="false">wrap</feature>
That's the only issue it is barfing on right now. I'll just have to run it down. [ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:4.0.5:assembly (process-resources) on project paypal-app: Unable to build assembly: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=wrap; type=karaf.feature; version=0; filter:="(&(osgi.identity=wrap)(type=karaf.feature)(version>=0.0.0))" [caused by: Unable to resolve wrap/0.0.0: missing requirement [wrap/0.0.0] osgi.identity; osgi.identity=org.ops4j.pax.url.wrap; type=osgi.bundle; version="[2.4.7,2.4.7]"; resolution:=mandatory [caused by: Unable to resolve org.ops4j.pax.url.wrap/2.4.7: missing requirement [org.ops4j.pax.url.wrap/2.4.7] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0)))"]] -> [Help 1] [ERROR] On Thu, Apr 28, 2016 at 9:30 AM, Brad Johnson <[email protected]> wrote: > Christian, > > Finally got a few minutes breathing room yesterday to work with some of > the new plugins. I like the karaf-maven-plugin and the features > generation. I'm not sure how much it is pulling that is absolutely > necessary and how much it is getting as just a scrape. It doesn't seem to > differentiate on the test scope. Those are obviously not items I'd want in > my features file. > > The karaf assembly kicks off fine but of course when I try to use it with > any of my existing projects I quickly run into a problem that my current > projects uses Fuse specific items and I'll have to switch my BOM to make it > work with the assembly. I'll do that if I get some time today. > > The assembly kicks off fine and pulls the karaf instance and begins but as > soon as it runs into my features file it pukes on some of the dependencies. > So the best bet would be to use the karaf-plugin and let it generate the > features file for all my projects and then use those in the startup. > > I'll give it a shot today and see what happens. > > Brad > > On Wed, Apr 27, 2016 at 8:51 AM, Brad Johnson < > [email protected]> wrote: > >> JB, >> >> That's why I haven't had a chance to work with it yet since I'm working >> in Fuse exclusively and it is still on karaf 2.x. So there hasn't been a >> chance to work with karaf 4 yet other than very basic stuff of running it. >> But with the static profiles doing a proof of concept and self-contained >> prototype for demo and testing means that working with karaf 4 isn't out of >> line. It's one of the issues I have with Fuse is that I'm always a step >> behind the world. Although it does seem like Karaf 3 was sort of brief >> resting spot on the way to karaf 4 anyway. >> >> So karaf-boot is leveraging the static profiles and using annotations to >> hook into that? I really think we may be in a back to the future situation >> with karaf. Ten years ago virtual machines as appliances were a new rage. >> Now they are rather common place. Docker is an extension and a slimming of >> that in a way. But karaf as appliances could really be an amazing market. >> With the amazing goodness of OSGi and the karaf shell and being able to SSH >> in to a container for management that's pretty interesting stuff. A whole >> different level of abstraction opens itself up. >> >> I think as much out of releasing the mind from concerns as anything. >> That's true when we started with OO and components and services and true at >> the appliance level as well. When you can look at an abstraction as a >> stand alone that can take care of its own needs you don't have to juggle it >> in your head. >> >> The other day I'd mentioned a gateway appliance I'd like. Feed it an >> appropriately decorated API interface and it creates server endpoints for >> incoming connections and makes client connections inward. But one could >> also have appliances for isolating databases behind web services. What the >> appliance makes possible is that physical and mental isolation where I just >> count on the service and don't have to think about how it co-exists in the >> same container with my other OSGi bundles. While we all work hard to make >> sure our exports and private packages are kept properly in their place in >> their bundles not every craftsman is equal in skill. And we all make >> mistakes. Karaf as an appliance mitigates that somewhat. If the young, >> bright developer I work with doesn't quite get the private package right >> and ends up with his bundle's contents exported to the world, well, if he's >> just exposing web services to isolate a database from the world then it >> isn't as serious a problem. >> >> Things like Drools rules engines with routes on JMS, SOAP, REST coming >> into it with a highly constrained set of rules for domain specific problem >> also become nifty little appliances. And so many of those have a nice fill >> in the logic feel to them. By that I mean that 90% of the Maven and >> profiles are the same. You just take the appliance outline and start >> working with the Camel, Java beans, and logic only. >> >> And testing! By God testing! >> >> Ahem. I don't know how many hours I've lost on CamelBlueprintTestSupport, >> PaxExam, and so on. If I can button up a nice appliance and simply run >> some JUnit tests with web services on a black box I'm a happy camper. One >> thing I've done in some of my tests environments that would work well with >> such black box appliances is put endpoint test simulator/stubs right in the >> bundles that are enabled/disabled by configuration flags. One project I'm >> on right now provides a set of services for the enterprise to get things >> like Invoices. Those REST and SOAP services use canonical models that have >> Dozer transforms to JDE models and a connection to JDE BSSVs (SOAP). >> During testing I set the flag and instead of using an OSGi service to talk >> directly to JDE it uses a different OSGi service that simply serves up >> dummy data from a map of XStream data models that I keep tucked away >> inside. But it let's me exercise all the routes, transforms, logic and >> deploy it early on for web tier folks to work against. With the static >> mechanics I can make an appliance of that and switch from test data to >> actual JDE with the flick of a configuration file setting. Or exercise it >> from my simple JUnit tests. And Jenkins should be simpler too. >> >> So yeah, this excites me a great deal. >> >> Brad >> >> On Wed, Apr 27, 2016 at 2:26 AM, Jean-Baptiste Onofré <[email protected]> >> wrote: >> >>> I don't think Karaf is a lot easier: it's a different approach, >>> different topology. It's not the same use case/packaging. >>> >>> It's exactly what karaf-boot is addressing: you use the annotations, we >>> deal with the packaging (you just define what you want). >>> >>> FYI, the static profile exists since 4.0.0 (it came with Karaf 4 and >>> profile introduction) ;) >>> >>> Regards >>> JB >>> >>> >>> On 04/27/2016 09:08 AM, Christian Schneider wrote: >>> >>>> I used the static profile here: >>>> https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-ds/app >>>> >>>> It allows to package a very slim karaf with your features. All bundles >>>> are directly referenced in the startup.properties. So there is no need >>>> for a feature service if your bundles are fixed. >>>> This makes karaf a lot easier to manage as you typically will not have >>>> refresh issues. >>>> >>>> The nice thing is that you can develop your application with normal >>>> features and decide about the packaging at a very late state. >>>> >>>> Christian >>>> >>>> On 26.04.2016 23:36, Brad Johnson wrote: >>>> >>>>> I looked at the profiles and static and find it interesting. I'll >>>>> have to work with it some. There's obviously a bit of a mind shift >>>>> there with the inheritance hierarchy. In my mind's eye I saw this as >>>>> something I'd run from a parent pom with a bunch of child bundle >>>>> projects but it would likely be better as an aside project separate >>>>> from the main build hierarchy itself. Which is fine. Decouples it as >>>>> a separate concern. Just a bit different than I'd imagined. >>>>> >>>>> I'll have to give it a swing. >>>>> >>>>> >>>> >>> -- >>> Jean-Baptiste Onofré >>> [email protected] >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> >> >> >
