zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andor Molnar <an...@apache.org>
Subject Re: [VOTE] Maven migration - separation of java files to server and client project?
Date Tue, 16 Oct 2018 10:30:20 GMT
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 <eolivelli@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
> <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