-runfw just sets the OSGi framework. Karaf basically also does this
inside when you can choose between felix and equinox but karaf is a lot
more than that.
So correctly setting up bndtools for karaf as a runtime will involve a
lot more than -rnfw.
I think there currently is not complete solution for this but I am also
be very interested in the combination of karaf and bndtools.
Christian
On 23.11.2016 17:18, Tim Ward wrote:
I was sort-of guessing that that's what -runfw was about, but didn't
find enough documentation to be able to understand it. Via monkey-see
monkey-do cut-and-paste I've ended up with
-runfw: org.apache.felix.framework;version='[5.6.1,5.6.1]'
which clearly does NOT tell it "you are running on Karaf, with
such-and-such list of other bundles installed".
Further, I was sort-of guessing that -runblacklist might be relevant
here, but was puzzled to find it expressed (in the GUI) in terms of
bundles? packages? rather than capabilities.
But it's not what I want, because putting the unwanted bundle in as a
blacklisted item gets me
==========================================================
Unable to resolve <<INITIAL>> version=null:
missing requirement com.telensa.apps.planet.p2c.provider
-> Unable to resolve com.telensa.apps.planet.p2c.provider
version=1.0.0.201611231522:
missing requirement org.osgi.service.component; version=[1.3.0,2.0.0)]
==========================================================
when I try to resolve.
Another point which might relate to duplicate scrs: in
http://enroute.osgi.org/appnotes/bndtools-and-karaf.html it says to do
|karaf@root(bundle)> feature:install scr|
Did that contribute to my problem? Should I alternatively uninstall
that feature?
On 23/11/2016 16:06, Timothy Ward wrote:
Isn’t this exactly what enRoute was trying to do with the distros?
Regards,
Tim
On 23 Nov 2016, at 16:05, Raymond Auge <raymond.a...@liferay.com
<mailto:raymond.a...@liferay.com>> wrote:
@Peter this is exactly a scenario I'd love to be able to eliminate
by exposing the target runtime as a repo which we can specify as the
the BASE for the resolver.
- Ray
On Wed, Nov 23, 2016 at 11:04 AM, Tim Ward <t...@telensa.com
<mailto:t...@telensa.com>> wrote:
So, if I manually delete
org.apache.felix.scr
from -runbundles then both symptoms go away.
All I've got to do now is try to find out how to stop the
Resolve button putting it back in every time?
On 23/11/2016 15:58, Peter Kriens wrote:
That sounds a bit like scr is started twice.
Sounds? Are their other possible explanations?
Kind regards,
Peter Kriens
On 23 Nov 2016, at 16:49, Christian Schneider
<ch...@die-schneider.net <mailto:ch...@die-schneider.net>> wrote:
On 23.11.2016 16:47, Tim Ward wrote:
OK, doesn't look like configuration.
- Comment out @RequireConfigureExtender
- Resolve
- Confirm that osgi.enroute.configurer.simple.provider no
longer appears in -runbundles
- Confirm that osgi.enroute.configurer.simple.provider no
longer appears in Karaf's "list" command
- Restart Karaf and run it again
and the same happens.
By the way, I also get the following from time to time in the
log, which I've ignored so far, but it does suggest that my
component isn't the only thing being started twice?
2016-11-23 15:43:43,266 | INFO | pool-61-thread-3 |
ScrServiceMBeanImpl | 55 -
org.apache.karaf.scr.management - 4.0.7 | Activating the
Apache Karaf SCR Service MBean
2016-11-23 15:43:43,268 | ERROR | pool-61-thread-3 |
ScrServiceMBeanImpl | 55 -
org.apache.karaf.scr.management - 4.0.7 | Exception
registering the SCR Management MBean:
org.apache.karaf:type=scr,name=root
javax.management.InstanceAlreadyExistsException:
org.apache.karaf:type=scr,name=root
at
com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)[:1.8.0_60]
That sounds a bit like scr is started twice.
Christian
--
--
Tim Ward
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
