zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Han <h...@apache.org>
Subject Re: [VOTE] Maven migration - separation of java files to server and client project?
Date Tue, 23 Oct 2018 17:31:22 GMT
+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 <andor@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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message