Thanks Norbert for taking care of this. No surprise here in a 10+ year old project.
-1 (binding) for the separation Let’s keep server + client + common together for now. We can revisit this later, but the pro is that we keep the release artifact structure and not introducing breaking changes. Regards, Andor > On 2018. Oct 16., at 9:15, Enrico Olivelli <[email protected]> wrote: > > Yes, > I think it is NOT a good idea to go ahead with this separation. > > so -1 (non binding) from my side for now > > And your patch is very good at demonstrating this. > We can't break compatibility in clients. > > We can move to Maven first and then re-think about separating client and > server > > Enrico > > Il giorno lun 15 ott 2018 alle ore 23:55 Norbert Kalmar > <[email protected]> ha scritto: >> >> Sorry, I linked the document instead of the PR. I wanted to link the >> document at the beginning of the letter after "It was said here" >> >> The PR: >> https://github.com/apache/zookeeper/pull/670 >> >> Norbert >> >> On Mon, Oct 15, 2018 at 11:49 PM Norbert Kalmar <[email protected]> >> wrote: >> >>> Hi community! >>> >>> As outlined in the start document, it was planned to separate the java >>> files to server and client, with common files in a separate common module. >>> It was said here: >>> >>> "Fifth iteration - move src/java/main to zk-server, which will be further >>> separated in Phase 2." >>> >>> But in order to save rebase for the contributors, I merged this into one >>> step. (I had a letter about it) >>> So I already created zookeeper-server, zookeeper-client and >>> zookeeper-common. >>> >>> But after doing the separation, I have to say... this just hardly makes >>> any sense. >>> Without breaking backward compatibility by making changes in the package >>> structure, it just makes the code more unreadable than before. Multiple >>> packages has to be present in all 3 modules (as it was never an intention >>> to separate it, so many classes are just not in their logical package, and >>> even inner classes used when top level would be required for the >>> separation). Client and server code can not be divided to only depend on >>> common. Either server depends on client - which makes more sense than the >>> other option - or client depend on server. >>> (Or make common so fat, only literally a few class remains in server and >>> client - which again, makes no sense). >>> >>> I created a pull request to illustrate what needs to be done, and this is >>> not even half complete: >>> >>> https://docs.google.com/document/d/1WXqhaPlCwchcWc8RCEzbCmVa4WbBDlfR3GQngikGjqc/edit?usp=sharing >>> >>> Some more detail in the description. >>> >>> My suggestion: >>> forget about zookeeper-client-java and zookeeper-common, and just leave >>> zookeeper-server. >>> >>> It just doesn't make any sense looking at the result, only makes the >>> project much more complicated. The java code is too much tangled together. >>> >>> What would this mean if I just create zookeeper-common? All the files had >>> to be renamed anyway, so some now would have 2 renames (fortunately most of >>> the files are in zookeeper-server anyway), and possible another rebase for >>> some PR's. >>> >>> Any input is appreciated. >>> >>> Regards, >>> Norbert >>> >>> >>> >>>
