db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Charlie Mordant (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (DERBY-6586) CLONE - derbyclient.jar conflict with derby.jar on package export, which is problematic on OSGI environment
Date Sat, 05 Mar 2016 21:06:40 GMT

    [ 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 package 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.
* 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).


> 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)

Mime
View raw message