+1 (for keep server, client and common together). We can do client / server split separately. Interestingly, there was an outstanding JIRA about the split, which we could use after maven build is live: https://issues.apache.org/jira/browse/ZOOKEEPER-233
On Tue, Oct 16, 2018 at 3:30 AM Andor Molnar <an...@apache.org> wrote: > 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 <eolive...@gmail.com> 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 > > <nkal...@cloudera.com.invalid> 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 <nkal...@cloudera.com> > >> 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 > >>> > >>> > >>> > >>> > >
