You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Charlie Mordant (JIRA)" <ji...@apache.org> on 2016/03/05 22:06:40 UTC

[jira] [Comment Edited] (DERBY-6586) CLONE - derbyclient.jar conflict with derby.jar on package export, which is problematic on OSGI environment

    [ https://issues.apache.org/jira/browse/DERBY-6586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15181846#comment-15181846 ] 

Charlie Mordant edited comment on DERBY-6586 at 3/5/16 9:06 PM:
----------------------------------------------------------------

Hi,

The OSGi bundle's rule (jars) are pretty easy to understand:
* You can't have two different bundles (jars) exporting the same packages otherwise they must have different versions (and shall respect the semantic versioning paradigm: macro qualifier for major api changes (e.g. consumer api), minor for minor changes (e.g. developper api), micro for patches. Otherwise, these bundles (jar) cannot coexist within the same OSGi runtime.
* Also, jars cannot have circular packages dependencies (com.foo having classes importing ones from com.bar having importing some from a package which import one from com.foo)

As derby.server and derby.client are exporting the same packages (there classes in the org.apache.derby package in the derby-client jar and also in the derby-server jar), they can't really coexist in an OSGi runtime (there are hacks like using Require-Bundle Manifest option instead of the Import-Package one, or making a super-bundle encompassing these two, but this breaks to some modularity capabilities and it's just evil).



was (Author: tcharl):
Hi,

The OSGi bundle's rule (jars) are pretty easy to understand:
* You can't have two different bundles (jars) exporting the same packages otherwise they must have different versions (and shall respect the semantic versioning paradigm: macro qualifier for major api changes (e.g. consumer api), minor for minor changes (e.g. developper api), micro for patches. Otherwise, these bundles (jar) cannot coexist within the same OSGi runtime.

As derby.server and derby.client are exporting the same packages (there classes in the org.apache.derby package in the derby-client jar and also in the derby-server jar), they can't really coexist in an OSGi runtime (there are hacks like using Require-Bundle Manifest option instead of the Import-Package one, or making a super-bundle encompassing these two, but this breaks to some modularity capabilities and it's just evil).


> CLONE - derbyclient.jar conflict with derby.jar on package export, which is problematic on OSGI environment
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-6586
>                 URL: https://issues.apache.org/jira/browse/DERBY-6586
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client, Network Server
>    Affects Versions: 10.10.2.0
>         Environment: OSGi
>            Reporter: Charlie Mordant
>
> The manifest in derbyclient.jar is incomplete for usage in OSGi.  There are no packages exported.  This appears to only be a problem in standalone equinox (outside of eclipse).  Note that I did not try other OSGi containers.
> The fix is relatively simple.  Adding the Export-Package manifest header should take care of the problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)