On 21. Aug 2008, at 16:12, Sahoo wrote:
> Since you are delivering a single metro bundle that contains
> everything, how exporting implementation packages help? Are those
> packages used by other bundles?
We already had to export a lot of supposedly private packages that
contained classes that were looked up through META-INF/services. We
also saw issues loading properties for localized log messages.
Typically every package has one property file in Metro. As it stands,
we would probably have spent weeks (on top of the existing two months
we put into this already) iteratively chasing down all these packages
and exporting them. Since our test coverage is not 100% we could not
have been certain that we really exported all packages that had to be
exported. Altogether, I believe we would have had to export so many
packages that we might as well export all of them and be on the safe
side.
Fabian
> Fabian Ritzmann wrote:
>> Hi,
>>
>> I had originally planned to export only those Metro packages for
>> the GF V3 OSGi bundles that were public interfaces, e.g.
>> java.xml.ws, com.sun.xml.ws.api, etc. However we have had issues
>> e.g. loading property files for localized log messages if the
>> packages that contained these files were not exported. I have
>> changed my thinking and I believe now that exporting all packages
>> for a stack like Metro is the right thing to do for various reasons:
>>
>> - Rearchitecting Metro to employ OSGi services internally is far
>> too much work, i.e. we have to continue using the existing logging,
>> service lookup, etc. mechanisms already implemented in Metro.
>>
>> - The Metro stack consists of dozens of libraries that may be
>> combined and run in an uncontrollable amount of environments. These
>> libraries can not rely on the availability of an OSGi container.
>>
>> - Exporting all packages is not worse than what we have in GF V2,
>> where all packages are available globally through the regular Java
>> classloading mechanisms.
>>
>> Fabian