> > 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. 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 > >
