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é <[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]>>
>> 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]>>
>>
>> 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]>> 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é
>> [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
>
