| Re: [orbit-dev] Bundle packaging question: best practice for importing packages potentially provided by a JDK |
I will attempt to answer some of your questions, but I think others should chime in with their opinion as well.
The "version" of the packages exported by the VM (or OSGi system bundle) is tricky. Currently both Equinox and (the latest) Felix framework implementations export the VM provided packages at version 0.0.0. Richard Hall and I have come to an agreement to add some qualifiers to the end of the VM package versions to reflect the execution environment, but we have not done this in Equinox for Helios (see https://issues.apache.org/jira/browse/FELIX-995). I agree with you, for bundles that can use the non-java.* packages from the VM (e.g. javax.xml.parsers) should import these packages without a version. This should be safe as long as the bundle specifies a Bundle-RequiredExecutionEnvironment for the VM they require. This should ensure that the proper non-java.* package is available for them to resolve.
Also note that we have a tooling deficiency that does not flag an error/warning for access to non-java.* without the use of a proper constraint (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=164188). This makes it difficult to detect the packages you should using Import-Package for.
The more tricky part is for bundles that are providing additional content to the package in the VM and bundles that are providing complete replacements to the content in the VM.
Case 1) addition content - The typical example is the javax.transaction package. As most folks may know the javax.transaction package included in the JavaSE VMs is incomplete and only contains a few exception clases. In many cases we need the complete package, but we want to reuse the content from the VM. This is the case Hugues outlines below. In this case the bundle must require the system.bundle in order to allow the OSGi delegation to reuse the VM's content for the javax.transaction package and then allow the bundle exporting javax.transaction to add its additional content. This can only work as long as the bundle exporting the javax.transaction package is compatible with the content of the javax.transaction package in the VM. The export of the package (javax.transaction) needs to have some additional attributes to allow bundles to specify a requirement on the "complete" package. In most cases I have seen the version attribute be used for this. This is only possible as long as the frameworks use a 0.0.0 version for the package so that higher versions can be used as a preference over the lower "incomplete" version in the VM.
Case 2) complete replacement - Sometimes a complete replacement is needed of a non-java.* package in the VM. In this case the exporter of the package does not want clients to delegate to the VM for the package they are exporting. In this case the bundle must not require the system.bundle because it must not delegate to the VM for the package it is exporting. This adds much more complexity because now we will have multiple exporters of the same package and they will be incompatible, causing class cast exceptions. This is where the "uses" clause is necessary to ensure bundles have a consistent class space.
If possible bundles should try to fall into case 1. If they fall into case 2 then we need to be aware of the issues that can arise from an inconsistent class space where some set of bundles are wired to the VM version of the package while others are wired to another incompatible version.
Tom
orbit-dev-bounces@xxxxxxxxxxx wrote on 06/18/2010 01:30:42 PM:
> From:
>
> Hugues Malphettes <hmalphettes@xxxxxxxxxxx>
>
> Hi everyone,
>
> I am struggling with the best practices for importing packages
> provided by a JDK and an execution profile: javax.*, org.xml.sax,
> org.w3c etc.
>
> Until now I was simply omitting them and thanks to the bootdelegation
> of equinox everything would work fine:
> http://wiki.eclipse.org/Equinox_Boot_Delegation
> Not importing those packages explicitly would obviously avoid any kind
> of package conflict detection: my bundles would work fine with other
> bundles that choose to import those packages regardless of the
> constraints they would declare.
>
> When we strictly follow the OSGi spec we must turn off the
> bootdelegation and import those packages.
> For example: https://bugs.eclipse.org/bugs/show_bug.cgi?id=317007
>
> Is this something that in general the orbit bundles should strive tosupport ?
>
> If we are supporting this situation: how should we import the jdk packages?
> With a version or without?
>
> In my opinion we should import them without version.
>
> In those cases where we need in fact to import a more modern version
> of the package than what the jdk potentially provides we should use
> another bundle that is a fragment to the system bundle and "extends"
> the system bundles in that manner.
>
> For example that is what javax.transaction does:
> Fragment-Host: system.bundle
> Bundle-RequiredExecutionEnvironment: J2SE-1.5
> Bundle-Name: %Bundle-Name.0
> Bundle-SymbolicName: javax.transaction
> Export-Package: javax.transaction.xa;version="1.1",
> javax.transaction;version="1.1"
>
>
> Please let me know,
> Hugues
> _______________________________________________
> orbit-dev mailing list
> orbit-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/orbit-dev