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
>
