> 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
