Just looked at the local demo copy in the karaf 4 distro and I think that gives me a clearer idea of what I need to do to set up a project. I'm sort of wedging this effort in between my normal work so the time is limited but it looks fairly clear I think.
I'll probably slurp that into Eclipse and run it and see how that looks and just modify it backward. On Thu, Apr 28, 2016 at 12:10 PM, Brad Johnson <[email protected] > wrote: > 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 < > [email protected]> 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é <[email protected]> >> 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é <[email protected] >>>> <mailto:[email protected]>> 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 >>>> <[email protected] >>>> <mailto:[email protected]> >>>> <mailto:[email protected] >>>> >>>> <mailto:[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] >>>> <mailto:[email protected]> >>>> <mailto:[email protected] >>>> >>>> <mailto:[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] <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[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 <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é >>>> [email protected] <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>> >>>> http://blog.nanthrax.net >>>> Talend - http://www.talend.com >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Jean-Baptiste Onofré >>>> [email protected] <mailto:[email protected]> >>>> http://blog.nanthrax.net >>>> Talend - http://www.talend.com >>>> >>>> >>>> >>> -- >>> Jean-Baptiste Onofré >>> [email protected] >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> >> >> >
