Il giorno gio 16 mag 2019 alle ore 13:25 Norbert Kalmar <[email protected]> ha scritto:
> Hi Jiri, > > Thank you for investigating this issue. > > Short summary what we already talked about on the PR: > I don't think we can change the package name on 3.5 branch, even though > this is not exposed through the client API. But for 3.6, from my point of > view, sure. > But that would mean go with solution #1 on 3.6 and go with #2 on 3.5 > branch. > I think that a new zookeeper-osgi dependency would be a problem. We are talking about Curator here and if Curator has a dependency with zookeeper-osgi, applications that are depending on both Curator and directly ZookKeeper will have an "interesting" mess to solve (I have a bunch of them). We can rename the package names even in 3.5 branch if a client application does not "link" to those package names directly. I am thinking about the other problem we had (still not resolved) while creating a standalone zookeeper-client. We could not strip out the java client part because of org.apache.zookeeper.server.quorum.QuorumPeerConfig.ConfigException, which used by ZKClientConfig. We should inspect an existing client compiled against ZK 3.4 and see if it is fully working with zookeeper-server + zookeeper-jute with jute packages renamed. If it fully works we are safe and we can go with #1 even on 3.5 branch. It would be great to break binary compatibility in 3.6 (an maybe call it 4.0.0) only once and create a standalone java client, compatible with Osgi. We have a 3rd possibility: we could "shade" the zookeeper-jute jar inside the "public" zookeeper jar, so that the result is exacly the same as 3.5.4-beta If option 1 is not working I would go for 3 , that is: only one osgi compatible bundle named exacly the 3.5.4-beta one Enrico > > But for me, #2 is also acceptable for both branches. > > Regards, > Norbert > > On Thu, May 16, 2019 at 1:18 PM Jiří Ondrušek <[email protected]> > wrote: > > > Hi, > > > > 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* > > > > > > Solution: > > > > > > 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, > > Jiri > > > > > > [1] https://issues.apache.org/jira/browse/ZOOKEEPER-3389 > > [2] https://github.com/apache/zookeeper/pull/945 > > >
