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
>>
>
>
