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 <[email protected]>
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 <[email protected]>
>> 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 <
>>>> [email protected]> 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 <[email protected]> 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 <
>>>>>>
>>>>>> [email protected]>
>>>>>
>>>>> 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: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
