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
