In this particular case removing scr from Karaf is OK because there is nothing in it that needs it. That would not be a universal solution though. Same thing with deploying through agent - works perfect in such experiment green field cases but that's likely not how one would deploy in big projects. Different combinations of runtimes and build tools would likely need to be resolved in different ways.
I don't have any universal solution for that but at least I finally managed to understand Ray's point about resolving against specific runtimes which seemed a weird idea up until now. Best, Milen On Wed, Nov 23, 2016 at 5:35 PM, Christian Schneider < ch...@die-schneider.net> wrote: > Good question. I think one issue with not installing the scr feature is > that you do not have the scr karaf commands. > Apart from that not installing the scr feature would make it easier for > bndtools users. > > Maybe you can create a pull request on the documentation and discuss with > the maintainers if the change is good. > > Christian > > > On 23.11.2016 17:27, Tim Ward wrote: > > OK, so if I feature:uninstall scr from Karaf I can let Resolve do its > thing and everything works. > > Is that an error in > > http://enroute.osgi.org/appnotes/bndtools-and-karaf.html > > then? > > On 23/11/2016 16:23, Christian Schneider wrote: > > -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> 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> 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> >> 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 > listosgi-...@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev > > > > -- > Christian Schneiderhttp://www.liquid-reality.de > > Open Source Architecthttp://www.talend.com > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- http://about.me/milen
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
