So just with these three dependencies - static features, static kar, and standard features - I get this. But that may simply be incomplete project definition on my part and means I have to step back and take a deeper and more concerted look at how this is all set up.
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] <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> On Thu, Apr 28, 2016 at 11:50 AM, Brad Johnson <brad.john...@mediadriver.com > wrote: > JB, > > I'll take you up on that when I have a better idea of what I'm doing with > it. I work with features in Fuse all the time but I'm not sure of the > static mechanics and so was just taking baby steps. When I hit a spot that > obviously was my bad I stopped and had to rethink how to approach this. > Probably download your full example and pare it back. For example, the > following very simple POM taken from Christians sample will pull everything > fine and zip up until I add in the standard or enterprise features. That's > probably because I'm missing other dependency information or plugins. > That's not really something I can expect you to help me with as I'm > obviously misusing/abusing the idea. > > > > > <groupId>com.foo.bar</groupId> > <artifactId>foo-app</artifactId> > <version>1.0.1-SNAPSHOT</version> > > > <packaging>pom</packaging> > > <properties> > <karaf.version>4.0.5</karaf.version> > </properties> > > <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> > > *//If I add either of these then I start getting errors which I'm going to > guess is because I'm missing necessary dependencies.* > *//or configuration data.* > <!-- <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.svm.esb.payments</groupId> > <artifactId>features</artifactId> > <classifier>features</classifier> <type>xml</type> > <scope>compile</scope> > <version>${project.version}</version> </dependency> --> > </dependencies> > <build> > <resources> > <resource> > <directory>src/main/resources</directory> > </resource> > </resources> > <plugins> > <plugin> > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-resources-plugin</artifactId> > <executions> > <execution> > <id>process-resources</id> > <goals> > <goal>resources</goal> > </goals> > </execution> > </executions> > </plugin> > <plugin> > <groupId>org.apache.karaf.tooling</groupId> > <artifactId>karaf-maven-plugin</artifactId> > <version>${karaf.version}</version> > <executions> > <execution> > <id>process-resources</id> > <phase>process-resources</phase> > <goals> > <goal>assembly</goal> > </goals> > </execution> > <execution> > <id>package</id> > <goals> > <goal>archive</goal> > </goals> > </execution> > </executions> > <configuration> > <javase>1.8</javase> > <startupFeatures> > > *//Not even attempting this yet.* > > </startupFeatures> > </configuration> > </plugin> > > </plugins> > </build> > > On Thu, Apr 28, 2016 at 10:32 AM, Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > >> Hi Brad, >> >> can you share the complete pom.xml ? I will help to fix it. >> >> Thanks, >> Regards >> JB >> >> >> On 04/28/2016 05:29 PM, Brad Johnson wrote: >> >>> 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 <http://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 >>> <mailto: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> >>> <mailto: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> >>> <mailto: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> >>> <mailto: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> >>> <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> >>> <mailto:jbono...@apache.org <mailto:jbono...@apache.org>> >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> >>> >>> >>> >>> >>> -- >>> 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 >> > >