> On 27 Oct 2015, at 22:45, Balázs Zsoldos <balazs.zsol...@everit.biz> wrote: > >> >> As an application developer, you don’t need to import anything from >> extender bundles. >> I would estimate that 90% of my bundles do not import anything from the >> core OSGi framework, and I almost *never* write a BundleActivator. > > > Probably "Import" was not the right word. As an application developer, you > either have to implement BundleActivator, or use some technology that > implements the extender pattern. That technology must either implement > BundleActivator or use another technology that implements another extender > pattern. And so on... > > If org.osgi.framework is not part of the system packages, at least one of > the bundles will not be able to resolve (the one that implements > BundleActivator). As a result, no code will be executed in any of the > bundles. (It can be executed if someone starts the framework > programmatically than gets a class type from one of the bundles than > instantiates it with reflection... I do not think anybody wants to do this). > > In other words: The org.osgi.framework must ALWAYS export the > org.osgi.framework package, otherwise no business logic will be executed.
Umm… yes. Luckily it already does this. Sorry, struggling to see the deeper point you are making. > > > On Tue, Oct 27, 2015 at 11:18 PM, Neil Bartlett <njbartl...@gmail.com> > wrote: > >> >>> On 27 Oct 2015, at 17:33, Balázs Zsoldos <balazs.zsol...@everit.biz> >> wrote: >>> >>>> >>>> As an application developer, I don't need to implement the extender >>>> pattern since framework developers have done that for me. It's all about >>>> layers and perspective. >>> >>> >>> As a technology developer, how would you implement an extender pattern >>> without the framework packages? You could not. If those packages are not >>> exported by the system bundle, you cannot implement the extender pattern. >>> As an application developer, you could not import a bundle that >> implements >>> the extender pattern, as the bundle would not resolve. >> >> >> As an application developer, you don’t need to import anything from >> extender bundles. >> >> I would estimate that 90% of my bundles do not import anything from the >> core OSGi framework, and I almost *never* write a BundleActivator. >> >> Regards, >> Neil >> >> >>> >>> You mean that the Framework developers should implement technologies like >>> Declarative Services and include it into the Framework? >>> >>> >>> On Tue, Oct 27, 2015 at 6:27 PM, Richard S. Hall <he...@ungoverned.org> >>> wrote: >>> >>>> On 10/27/15 13:14 , Balázs Zsoldos wrote: >>>> >>>>> That is not my interpretation. System packages are those packages >> provided >>>>>> by the system bundle. From a wiring perspective, all of the JRE >> packages >>>>>> look like they are coming from the system bundle just like the OSGi >> core >>>>>> packages, so your distinction doesn't really make sense to me. >>>>>> >>>>> >>>>> Seems that we are different :). I interpret rules based on use-cases. I >>>>> cannot find any use-case where I wanted to handle framework packages >> like >>>>> JDK packages. On the other hand, I see use-cases where I want to handle >>>>> them separately. >>>>> >>>> >>>> It is much more consistent to defines system.packages like, >>>> "system.packages represents all packages that will be exported by the >>>> system bundle", instead of something like "system.packages represents >> all >>>> packages exported by the system bundle plus some additional packages >> that >>>> will tacked on but may vary by framework implementation". >>>> >>>> >>>>> Wrong. The extender pattern is based almost wholly around such an >>>>> approach. >>>>> >>>>> >>>>> How would you implement the extender pattern without the framework >>>>> packages? >>>>> >>>> >>>> As an application developer, I don't need to implement the extender >>>> pattern since framework developers have done that for me. It's all about >>>> layers and perspective. >>>> >>>> -> richard >>>> >>>> >>>> >>>>> >>>>> >>>>> On Tue, Oct 27, 2015 at 6:04 PM, Richard S. Hall <he...@ungoverned.org >>> >>>>> wrote: >>>>> >>>>> On 10/27/15 11:27 , Balázs Zsoldos wrote: >>>>>> >>>>>> @David: >>>>>>> >>>>>>> I know about the *org.osgi.framework.system.**packages.extra* >> property, >>>>>>> but >>>>>>> that is about another use-case. >>>>>>> >>>>>>> *org.osgi.framework.system.**packages.extra *can be used to extend >> the >>>>>>> list >>>>>>> of system packages. >>>>>>> *org.osgi.framework.system.**packages* can be used to reduce the >> list of >>>>>>> the system packages. >>>>>>> >>>>>>> I want to reduce the list of system packages as some packages are >> coming >>>>>>> from bundles. More specifically, I want to list only those packages >>>>>>> that I >>>>>>> actually need from the JDK. Reason: Many packages are incomplete or >>>>>>> buggy >>>>>>> in the JDK: javax.transaction.*, javax.xml.*... >>>>>>> >>>>>>> @Andy: >>>>>>> >>>>>>> The text at >>>>>>> >>>>>>> >>>>>>> >> https://osgi.org/javadoc/r5/core/org/osgi/framework/Constants.html#FRAMEWORK_SYSTEMPACKAGES >>>>>>> says:* Framework launching property identifying packages which the >>>>>>> system >>>>>>> bundle must export.* >>>>>>> >>>>>>> "Must" does not mean that only those packages should be exported by >> the >>>>>>> system bundle. >>>>>>> >>>>>>> @Everyone: >>>>>>> >>>>>>> Questions: >>>>>>> >>>>>>> - What is the exact meaning of system packages from the >>>>>>> perspective of >>>>>>> this setting? In my opinion, the list of packages that are coming >>>>>>> outside >>>>>>> the OSGi container. >>>>>>> >>>>>>> That is not my interpretation. System packages are those packages >>>>>> provided >>>>>> by the system bundle. From a wiring perspective, all of the JRE >> packages >>>>>> look like they are coming from the system bundle just like the OSGi >> core >>>>>> packages, so your distinction doesn't really make sense to me. >>>>>> >>>>>> >>>>>> org.osgi.* packages do not come outside from the OSGi >>>>>> >>>>>>> container. >>>>>>> - Could the org.osgi.* packages come from custom bundles? I >> think, >>>>>>> no. >>>>>>> - Can you write an application that does not need any of the >>>>>>> org.osgi.* >>>>>>> package? I think you cannot.At least one bundle has to implement >> an >>>>>>> Activator to have any kind of functionality in the system. >>>>>>> Otherwise >>>>>>> the >>>>>>> bundles will be resolved, but they will do nothing (not even a >>>>>>> static >>>>>>> block >>>>>>> will be called). >>>>>>> >>>>>>> Wrong. The extender pattern is based almost wholly around such an >>>>>> approach. >>>>>> >>>>>> -> richard >>>>>> >>>>>> - Can you imagine any use-case where exporting org.osgi.* packages >>>>>> by >>>>>> >>>>>>> the system bundle could cause any issue? I cannot. >>>>>>> - Is it an extra work that org.osgi.* packages have to be >> appended >>>>>>> if >>>>>>> system.packages are overridden? Yes, always. >>>>>>> >>>>>>> If we answer these questions, we will come to the conclusion (at >> least I >>>>>>> :) >>>>>>> ) that org.osgi.* packages should always be exported by the system >>>>>>> bundle. >>>>>>> They are not in the scope of the meaning of system.packages setting. >>>>>>> >>>>>>> >>>>>>> Kind regards, >>>>>>> *Balázs **Zsoldos* >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Oct 27, 2015 at 3:21 PM, David Bosschaert < >>>>>>> david.bosscha...@gmail.com> wrote: >>>>>>> >>>>>>> Yes, that's precisely what the >>>>>>> >>>>>>>> org.osgi.framework.system.packages.extra was designed for. That way >>>>>>>> you don't need to remember what the framework puts on >>>>>>>> org.osgi.framework.system.packages in order to augment it. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 27 October 2015 at 14:18, Andy Lee <thelees.a...@gmail.com> >> wrote: >>>>>>>> >>>>>>>> If you are trying to extend the set of packages exported by the >> system >>>>>>>>> bundle, you should use org.osgi.framework.system.packages.extra. >> By >>>>>>>>> specifying org.osgi.framework.system.packages you are overriding >> the >>>>>>>>> default value used by the framework, and hence must include the >>>>>>>>> packaged >>>>>>>>> that are expected to be supplied by the framework. >>>>>>>>> >>>>>>>>> See >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >> https://osgi.org/javadoc/r5/core/org/osgi/framework/Constants.html#FRAMEWORK_SYSTEMPACKAGES >>>>>>>> >>>>>>>> --Andy >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Oct 27, 2015 at 10:00 AM, Balázs Zsoldos < >>>>>>>>> >>>>>>>>> balazs.zsol...@everit.biz> >>>>>>>> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>>> I asked this 1-2 years ago, but I think it is worthy to ask it >>>>>>>>>> again. >>>>>>>>>> >>>>>>>>>> Are you sure that the set of system packages should include the >> OSGi >>>>>>>>>> >>>>>>>>>> core >>>>>>>>> packages? >>>>>>>>> >>>>>>>>>> In my understanding: >>>>>>>>>> >>>>>>>>>> - system packages are the ones coming from outside of the OSGi >>>>>>>>>> >>>>>>>>>> container >>>>>>>>> - osgi core packages are offered by the framework bundle, but >>>>>>>>> they >>>>>>>>> are >>>>>>>>> not system packages >>>>>>>>> >>>>>>>>>> In practice: >>>>>>>>>> >>>>>>>>>> - If I specify org.osgi.system.packages property for equinox, >> I >>>>>>>>>> do >>>>>>>>>> >>>>>>>>>> not >>>>>>>>> have to define the packages implemented by the framework >>>>>>>>> >>>>>>>>>> - If I specify the same property for felix, I must copy-paste >>>>>>>>>> the >>>>>>>>>> packages of osgi.core always >>>>>>>>>> >>>>>>>>>> Do you think there is a use-case when osgi.core packages offered >> by >>>>>>>>>> the >>>>>>>>>> framework should be excluded from the exported packages of the >> system >>>>>>>>>> bundle? I think Equinox has the right behavior here. >>>>>>>>>> >>>>>>>>>> Do you see any chance to change this behavior in the future? >>>>>>>>>> >>>>>>>>>> Kind regards, >>>>>>>>>> *Balázs **Zsoldos* >>>>>>>>>> >>>>>>>>>> >> --------------------------------------------------------------------- >>>>>>>>>> >>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>>>>>>> For additional commands, e-mail: users-h...@felix.apache.org >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>>>>> For additional commands, e-mail: users-h...@felix.apache.org >>>>>> >>>>>> >>>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>>> For additional commands, e-mail: users-h...@felix.apache.org >>>> >>>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
