I just need to take the time to use the proper BOM and mechanics. I was trying to shortcut this by having the plugin run on my bundles and create features files for them and then use those features in the assembly. That was a real long shot because I'm using some older code and tied into a Fuse BOM. That it didn't just work isn't surprising. If I chop my dependencies down to just this it zips fine. If I put the standard features in it gives an error. But that is likely due to my project hierarchy and the items I use in the parent POM.
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=feature; type=karaf.feature; version=4.0.5; filter:="(&(osgi.identity=feature)(type=karaf.feature)(version>=4.0.5))" [caused by: Unable to resolve feature/4.0.5: missing requirement [feature/4.0.5] osgi.identity; osgi.identity=org.apache.karaf.features.core; type=osgi.bundle; version="[4.0.5,4.0.5]"; resolution:=mandatory [caused by: Unable to resolve org.apache.karaf.features.core/4.0.5: missing requirement [org.apache.karaf.features.core/4.0.5] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.ops4j.pax.url.mvn)(version>=2.4.0)(!(version>=3.0.0)))"]] -> [Help 1] [ERROR] <dependencies> <dependency> <groupId>org.apache.karaf.features</groupId> <artifactId>static</artifactId> <type>kar</type> <version>${karaf.version}</version> </dependency> <dependency> <groupId>org.apache.karaf.features</groupId> <artifactId>static</artifactId> <classifier>features</classifier> <type>xml</type> <scope>compile</scope> <version>${karaf.version}</version> </dependency> <!-- <dependency> <groupId>org.apache.karaf.features</groupId> <artifactId>standard</artifactId> <classifier>features</classifier> <type>xml</type> <scope>compile</scope> <version>${karaf.version}</version> </dependency> <dependency> <groupId>org.apache.karaf.features</groupId> <artifactId>enterprise</artifactId> <classifier>features</classifier> <type>xml</type> <scope>compile</scope> <version>${karaf.version}</version> </dependency> --> <!-- <dependency> <groupId>com.foo.my</groupId> <artifactId>features</artifactId> <classifier>features</classifier> <type>xml</type> <scope>compile</scope> <version>${project.version}</version> </dependency> --> </dependencies> On Thu, Apr 28, 2016 at 10:00 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Do you have framework and log <feature/> defined in your pom.xml ? > > Regards > JB > > On 04/28/2016 04:42 PM, Brad Johnson wrote: > >> <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 >> <brad.john...@mediadriver.com <mailto:brad.john...@mediadriver.com>> >> 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 >> <brad.john...@mediadriver.com <mailto:brad.john...@mediadriver.com>> >> >> 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é >> <j...@nanthrax.net <mailto:j...@nanthrax.net>> 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 <tel:26.04.2016%2023>: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é >> jbono...@apache.org <mailto:jbono...@apache.org> >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> >> >> >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >