zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrico Olivelli <eolive...@gmail.com>
Subject Re: [VOTE] Maven migration - separation of java files to server and client project?
Date Tue, 16 Oct 2018 07:15:04 GMT
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
<nkalmar@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 <nkalmar@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
> >
> >
> >
> >

Mime
View raw message