Not sure why you decided to move the discussion back here but fine with me, at least I'm not the one highjacking the thread :)
I agree with "well defined distros" but that only works for greenfield projects. There may be hundreds of variations of runtimes out there. Some vary basic examples: - felix/equinox with or without (scr, blueprint, fileinstall, gogo, ...) - karaf with or without (spring, jpa, cxf, ...) - liferay with or without tons of customizations And when you enter the world of internal corporate rules and "standards" this is easily becoming unmanageable on distro level only IMHO. So from my perspective proposed "-runprovided" is just scoped version of "-runrequires". We don't use distro for "-runrequires" but name the bundles we *know* we want in *this project*. Same should be for things we *know* will be provided for *this project* IMHO. Regards, Milen On Thu, Nov 24, 2016 at 12:16 PM, Daghan ACAY <daghana...@hotmail.com> wrote: > Joining this thread these with Tim's other email about *-runprovided*. > > It reminds me the Set theory in maths. One can define the very same set by > saying > > 1- -distro: liferay > 2- distro: karaf minus -runblacklist > 3- -runprovided(example) plus -runrequires. > > I hope i am not missing crucial detail by trying to simplify it. But > assuming my simplification is valid, i prefer we have major -distro's which > we can fine tune them with the existing -runblacklist and -runrequires. > > This being said, distros should be well defined and we'll documented and > minimal in number. I guess this is one thing enroute is trying to solve. > Osgi is great but leaves to much to the developer and configuration. It > might benefit osgi to go convention over configuration. > > To be honest very little talks about using Spring with different app > serves mixing cxf instead of Spring REST etc. IMHO we are spoiled with > options and we want more for the sake of asking for it. > > Now my question is: can osgi/enroute provide well defined distros in the > near future. Some examples might be: > > 1-karaf > 2-felix/enroute > 3- equinox/eclipse > 4- possibly servicemix > > Or should we start creating or own distros? > > I hope i did not derail the discussion. > > Regards > Daghan > > Sent by MailWise <http://www.mail-wise.com/installation/2> – See your > emails as clean, short chats. > > > -------- Original Message -------- > From: Raymond Auge <raymond.a...@liferay.com> > Sent: Thursday, November 24, 2016 03:49 AM > To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> > Subject: Re: [osgi-dev] Component being activated twice? > > 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 > -- http://about.me/milen
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
