Yeah, now that Karl reminds me, I think he is correct. We don't re-parse
the manifest, we do getHeaders() and parse the results of that. On
Felix, this should return the correct value.
-> richard
Karl Pauls wrote:
I disagree. The system package should make javax packages available in
its manifest if they are exported by the system bundle (and Felix will
do so in case it is configured correctly). Why would the system bundle
export packages that are not in it's manifest? Now, equinox doesn't do
so but that doesn't imply that we have to change anything - maybe a
bug report against equinox is more in order?
The spec says the system bundle's getHeaders should contain an
Export-Package header that contains a list of packages that are to be
exported by the framework -- hence, I'd say its a bug in equinox.
regards,
Karl
Yes, you are probably correct...at least it sounds reasonable.
What we probably need to do is modify LocalRepositoryImpl to special
case the system bundle to calculate its exported packages differently...
Please feel free to look into this issue and/or create a JIRA issue
against OBR.
Thanks for follow up.
-> richard
Hampel, Michael wrote:
>
> Hello,
>
> After debugging the felix bundlerepository I think I found the problem why
the packages are not
> Found.
> When looking at the code of LocalRepositoryImpl the
initialization(initialize()) of a LocalResourceImpl instance
> Determines the exported packages of a local resource by examining its
manifest entries.
> Now, the system bundle (in my case equinox but I also think Felix) is not
exporting javax packages in its
> Manifest file - this is triggered via the org.osgi.framework.system.packages
property (I think).
> Therefore the OBR Resolver does not find these packages from the system
bundle.
> If I use the PackageAdmin to list the packages exported by the SystemBundle
then the framework system packages
> Are included (I think this is also how the Felix GUI gets the exported
packages for a bundle to display).
> Another solution was to read the FRAMEWORK_SYSTEMPACKAGES property from the
BundleContext to get the exported
> System packages.
> One of these solutions could be used to add the exported system packages to
the capabilities of the SystemBundle.
>
> Please let me know if I am on the right track and if so which solution you
would prefer and if the
> LocalRepositoryImpl could be changed.
>
> Thanx in advance for any help,
>
> Michael
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Hampel, Michael
> Gesendet: Donnerstag, 20. März 2008 13:21
> An: [email protected]
> Betreff: AW: obr resolving and system packages
>
> Hello again,
>
> I have now listed the exported packages of my system bundle and it contains
all javax and org.xml packages
> The OBR resolver is not able to find.
> Also the runtime is able to resolve and start the bundle with these package
dependencies.
> Could you please explain how the OBR resolver would find these packages?
>
> Thanx in advance,
>
> Michael
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Hampel, Michael
> Gesendet: Donnerstag, 20. März 2008 12:13
> An: [email protected]
> Betreff: AW: obr resolving and system packages
>
> Hello Richard,
>
> Thank you for your answer.
> I actually tried it.
> I have a directory where I put all my bundles in and which I use as the
repository.
> I then start the OSGi runtime (in my case equinox) plus the necessary
bundles for OBR handling
> within eclipse with the help of a run configuration.
>
> By saying
> "If your local system bundle exports javax.swing"
> do you mean that if I would start felix with a configuration file that
includes
> org.osgi.framework.system.packages=
> ${jre-${java.specification.version}}
> plus all java platform package export properties like
> jre-1.3=, \
> javax.accessibility; \
> javax.accessibility.resources; \
> javax.naming; \
> .....
>
> Then the OBR Resolver should find it from the system bundle?
>
> Thank you again for your help,
>
> Michael
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Richard S. Hall [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 20. März 2008 11:08
> An: [email protected]
> Betreff: Re: obr resolving and system packages
>
> Did you actually try this or are you just making an assumption?
>
> OBR treats the locally installed bundles as a repository too. So, if
> your local system bundle exports javax.swing, then it should resolve the
> package correctly...at least that is how it is supposed to work.
>
> -> richard
>
> Hampel, Michael wrote:
>
>> Hello,
>>
>> how do I deal with system package dependencies like javax.swing - that
>> an OSGi runtime would be able to resolve from the system classpath -
>> in the OBR resolving process.
>> If a resource in my repository.xml has a require element for javax.swing
>> the Resolver tries to find the dependency in one of my specified
>> repositories
>> but will not find it - so the OBR resolving for this resource will fail
>> although it would resolve in the runtime.
>> Is there a way to add system packages to the OBR resolving process or do
>> I have to specify all aof these packages as optional or do I see
>> this completely wrong?
>>
>> Thanx in advance for any help,
>>
>> Michael
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> 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]
>
>
> ---------------------------------------------------------------------
> 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]
