Hi, As an outcome of the discussion, I created two issues in Jira:
https://issues.apache.org/jira/browse/FELIX-5089 https://issues.apache.org/jira/browse/FELIX-5090 Regards, *Balázs **Zsoldos* On Tue, Oct 27, 2015 at 11:51 PM, Richard S. Hall <he...@ungoverned.org> wrote: > > > On Oct 27, 2015, at 18: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. > > This portion of the conversation has definitely gotten off track and I am > to blame since I was splitting hairs that shouldn’t have been split… > > Having said that, though, I did once create a custom launcher that simply > probed installed JAR files for some metadata and kicked started the > application from the outside (effectively, it was the extender pattern > implemented directly in a framework launcher). This work really nicely, > because it allowed the installed JAR files to benefit from module metadata, > encapsulate, and dependency resolution, but there was no code in the > application with any OSGi awareness. So, technically, in that case, the > system bundle needn’t have exported any OSGi packages at all, since the > launcher got access to them via the class path. > > See what kind of fun stuff you can do? :-) > > -> richard > > > > > > > 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 > >
