zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrico Olivelli <eolive...@gmail.com>
Subject Re: [SUGGESTION] Jute's place in the new directory structure
Date Tue, 28 Aug 2018 22:09:08 GMT
Il mar 28 ago 2018, 23:37 Brian Nixon <brian.nixon.cs@gmail.com> ha scritto:

> I still think it makes sense to keep it as a top level directory (would not
> include it in recipes). 'zookeeper-jute' is certainly a reasonable name. :)
>

+1 for zookeeper-jute

Enrico


> -Brian
>
> On Thu, Aug 23, 2018 at 7:59 AM Norbert Kalmar
> <nkalmar@cloudera.com.invalid>
> wrote:
>
> > Hi folks,
> >
> > So jute is a little bit the odd one out in ZooKeeper. It was pulled out
> of
> > Hadoop and it evolved independently since with ZooKeeper. And it has its
> > own namespace in ZK: org.apache.jute beside org.apache.zookeeper.
> >
> > For me, this is a bit odd, it suggests its a top level apache project.
> > The original plan in the maven migration was to move jute to simply in a
> > "jute" top level directory in zookeeper. Like this:
> >
> >
> > zookeeper | -bin | -conf | -jute | -zookeeper-client |
> -zookeeper-contrib |
> > -zookeeper-docs | -zookeeper-it (integration tests) | -zookeeper-server |
> > -zookeeper-recipes
> >
> > But this just seems a bit strange to me. I was thinking of possibly
> moving
> > into recipes, but then again, I ended up thinking it could still get its
> > own top level directory, but with the name "zookeeper-jute", as this
> > particular project is only used by ZooKeeper (of course I would keep the
> > package name intact).
> >
> > What do you think?
> > As this is a change that was not in the initial doc about maven
> migration,
> > I thought it's best to ask.
> >
> > Regards,
> > Norbert
> >
> > p.s.: The best thing would be to use a more standardized library for
> > serialization like protobuf or Avro. But that's just a distant dream
> right
> > now, maybe ZooKeeper v5.0 ;)
> >
>
-- 


-- Enrico Olivelli

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message