I guess your needs came from an environment I am not familiar with. I have never had to use Permissions within OSGi, so I must discontinue the argument here (until I get familiar once with OSGi security ;-) ).
Probably the different opinions come from the name "system.packages". If there were "framework.packages" and "environment.packages" that would give a better separation. The chance of having such discussion has gone long ago. Anyway, I would like to ask kindly you if it is possible to implement the idea that you (Richard) proposed in one of your previous emails: org.osgi.framework.system.packages= ${dollar}{framework-exports} \ ${dollar}{jre-${dollar}{java.specification.version}} That could save lots of work in the future for developers who want to specify explicitly those JDK packages they need. I hope that in one day all packages can come from bundles (all, even swing or other built-in solutions), and we need to export only the framework packages. On Tue, Oct 27, 2015 at 6:33 PM, Richard S. Hall <he...@ungoverned.org> wrote: > On 10/27/15 13:27 , Balázs Zsoldos wrote: > >> Also, we used to package some framework services separately (e.g., >>> PackageAdmin, etc.) and some framework still might, so this assumption >>> also >>> is not correct. >>> >> >> I am wondering why PackageAdmin had to be re-implemented. If it was >> possible to re-implement it based on other features of OSGi Core, does >> that >> mean that OSGi Core contained something that it should not have? If some >> services can be implemented based on others, they are more like libraries >> than part of the core. >> > > I didn't say it was re-implemented, I said it was packaged separately. We > still do, for example, package the permission-related services separately. > It did, however, use some special hooks to do what it needed to do. > > -> richard > > > >> E.g.: BundleTracker and ServiceTracker is part of a very helpful library. >> It can be implemented based on OSGi Core. I am probably alone with the >> opinion that is should not have been moved into OSGi Core. Also, it is >> another discussion (I am sure this was discussed internally before >> releasing OSGi Core 5). >> >> >> On Tue, Oct 27, 2015 at 6:08 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. 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). >>>> - Can you imagine any use-case where exporting org.osgi.* packages >>>> by >>>> the system bundle could cause any issue? I cannot. >>>> >>>> Also, we used to package some framework services separately (e.g., >>> PackageAdmin, etc.) and some framework still might, so this assumption >>> also >>> is not correct. >>> >>> - Is it an extra work that org.osgi.* packages have to be appended >>> if >>> >>>> system.packages are overridden? Yes, always. >>>> >>>> Sure, this is correct, but not really relevant to the meaning of system >>> packages. >>> >>> -> richard >>> >>> >>> 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 > >