zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jiří Ondrušek <ondrusek.j...@gmail.com>
Subject ZooKeeper and OSGi (maven)
Date Thu, 16 May 2019 11:10:58 GMT

I've created issue [1] with missing exported packages in osgi for
zookeeper 3.4.10. Then I started to prepare maven OSGi packaging [2]
for the higher version of ZooKeeper (in the PR for issue).

I've tried to implement OSGi packaging with the low impact. So I've
tried to create OSGi bundles from Zookeeper-server and from
zookeeper-jute modules.

But there is a *problem* for this solution:

   - zookeeper-jute has package 'org.apache.zookeeper.data', it has to be
   exported for zookeeper-server to use it
   - zookeeper-server contains also package 'org.apache.zookeeper.data',
   which has to be exported, because it is used from packages like
   org.apache.zookeeper, which are exported

-> *bundles can not be deployed into osgi as two libraries are exporting
the same packages*


   1. best solution is to change name of one of these packages (probably in
   module zookeeper-jute - which us used only by zookeeper) - but question is,
   whether this change is feasible
   2. only other solution is to create only one bundle (e.g.
   zookeeper-osgi), which will contain both libraries together and will expose
   their both packages at the same time (similar approach is used in e.g.
   hibernate-osgi, httpcore-osgi, httpclient-osgi)

Solution *#1* is a better solution, I would like to ask for your
opinion about feasibility of renaming zookeeper-jute generated
packages to not collide with zookeeper-server.
(As these packages are to be used only for zookeeper, it shouldn't
cause any harm)

If #1 is not acceptable, then we can go with #2. But I highly suggest
to consider renaming of zookeeper-jute's packages in the nearest point
in the future as possible and return to solution #1.

Best regards,

[1] https://issues.apache.org/jira/browse/ZOOKEEPER-3389
[2] https://github.com/apache/zookeeper/pull/945

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message