Given the current state of the art, what most affects your resolver output
starts with:
*-runee:* JavaSE-1.8 # this sets the base in terms of which JRE you are
targeting this is the fundamental parts provided by all JREs of a given
version
then you have:
*-distro:* <blah> # which is an *optional* pre-created jar with a manifest
containing all the capabilities provided by your "target platform", in your
case it's Karaf + whatever addons you've added to your karaf instance.
those two things define what should NOT be included in your resolve result.
Then your input is:
*-runrequires:* <blah> # this is your application you want to run. All the
bundle's you've defined here are the ones you absolutely want to have in
the runtime.
*-runblacklist:* <blah> # this is the set of bundles which you've
explicitly asked the resolver to never return in it's result.. but it
doesn't mean they're not already provided by your system.
For me the lynch pin to making this whole cycle complete would be that:
*-distro:* <blah>
represent the current reality, vs some snapshot in time which may no longer
be valid.
If it were possible to have that then you could theoretically point:
*-distro:* karak;index="socket:/..."
OR
*-distro:* liferay;index="file:/..."
OR
*-distro:* websphere;index="http:/..."
OR
*-distro:* my_super_custom_runtime;index="git:/..."
and your resolver operation would actually protect you from introducing
incompatible, or completely duplicated things.
If we took this a step further and had:
*-distro:* repo;name="liferay"
and have the repo config be:
*-plugin.distro.repo:* \
com.foo.super.LiveIndexOfRuntimeRepository; \
index="socket:/..."; \
name="liferay"
BOOM!!!!
Not only would I have resolution protection for those things I mentioned
above, but I could physically browse the runtime to see what's already
there.
- Ray
On Wed, Nov 23, 2016 at 11:27 AM, Tim Ward <t...@telensa.com> 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 List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
