You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by Norbert Kalmar <nk...@cloudera.com> on 2018/04/19 11:28:23 UTC

[SUGGESTION] Migrate project structure to Maven build

Hi ZooKeeper community,

As the vast majority of the components in the Hadoop ecosystem is built
with Maven, what do you think of moving Zookeeper to a Maven structure as
well?

This would bring the benefit of a more consistent project structure, better
dependency management and more possibilities for future changes (i.e.: we
could separate java client code so that projects like HDFS that only needs
the client doesn't have to import the whole ZooKeeper).

This could be done as a multi-step change.

The change would also include the separation of unit tests from integration
and/or functional tests.

In the first iteration, the project structure could be separated something
like:

zookeeper
|-bin
|-conf
|-zk-client-c
|-zk-contrib
| |-zk-contrib-fatjar
| |-zk-contrib-huebrowser
| |-zk-contrib-loggraph
| |-zk-contrib-monitoring
| |-zk-contrib-rest
| |-zk-contrib-zkfuse
| |-zk-contrib-zkperl
| |-zk-contrib-zkpython
| |-zk-contrib-zktreeutil
| \-zk-contrib-zooinspector
|-zk-docs
|-zk-it (integration tests)
|-zk-server
|-zk-recipes
| |-zk-recipes-election
| |-zk-recipes-lock
\ \-zk-recipes-queue


With this kind of structure, the code change could be kept to a bare
minimum, if any at all.
Just change the ant script to conform to the new structure.

In a second iteration, we could start the changes that require code changes
as well:

zookeeper
|-bin
|-conf
|-jute
|-zk-client
| |-zk-client-c
| |-zk-client-java
| \-zk-client-go (or any other language)
|-zk-common
|-zk-contrib
| |-zk-contrib-fatjar
| |-zk-contrib-huebrowser
| |-zk-contrib-loggraph
| |-zk-contrib-monitoring
| |-zk-contrib-rest
| |-zk-contrib-zkfuse
| |-zk-contrib-zkperl
| |-zk-contrib-zkpython
| |-zk-contrib-zktreeutil
| \-zk-contrib-zooinspector
|-zk-docs
|-zk-it (integration tests)
|-zk-server
|-zk-recipes
| |-zk-recipes-election
| |-zk-recipes-lock
\ \-zk-recipes-queue


Here, java client code is separated from the server code (and any other
supported languages client code).

The final iteration would be something like:

zk-something
|-src
| |-main
| |  |-java
| |  | \org...
| |   \resources
| \test (unit tests only?)
|  |-java
|  |  \org...
|  \resources
\pom.xml


But this is just to give a high level example/vision.

Of course, with all the iteration, even at the end when possibly moving to
a full Maven build, it is important that the final jar structure remains
the same.

What do you think?

Kind regards,
Norbert

Re: [SUGGESTION] Migrate project structure to Maven build

Posted by Norbert Kalmar <nk...@cloudera.com>.
Quick update: I created the umbrella jira and the first step sub-jira:
https://issues.apache.org/jira/browse/ZOOKEEPER-3021

Please feel free to pitch in, share your ideas and doubts.

I will start working on the first step.

Regards,
Norbert

On Fri, Apr 20, 2018 at 12:00 PM, Norbert Kalmar <nk...@cloudera.com>
wrote:

> Hi All,
>
> Thanks for the feedbacks.
> @Enrico: I checked https://issues.apache.org/jira/browse/ZOOKEEPER-1078 .
> It is very hard to keep track with the patch files, it should be committed.
> But looking at the changes, it is more of a Maven proxy layer for ant with
> lots of copy commands.
>
> If we do change to maven, I think we should do so with getting rid of ant.
> (Of course this will be one of the last steps). ZOOKEEPER-1078 approaches
> the task to add support for Maven build via just a proxy layer over ant.
>
> As @Mohammad mentiend, we could create an umbrella Jira, and start small
> (or at least small in the sense of coda change/impact).
>
> Looking at the reactions here, comments on ZOOKEEPER-1078 and other
> forums, I think people would be positive to the change.
>
> I will create the Umbrella Jira, so that we can start working on the first
> steps, while waiting for other feedbacks.
>
> Thanks,
> Norbert
>
> On Thu, Apr 19, 2018 at 2:53 PM, Ted Yu <yu...@gmail.com> wrote:
>
>>  +1 for migrating to maven build.
>> -------- Original message --------From: Mohammad arshad <
>> mohammad.arshad@huawei.com> Date: 4/19/18  5:23 AM  (GMT-08:00) To:
>> dev@zookeeper.apache.org Subject: RE: [SUGGESTION] Migrate project
>> structure to Maven build
>> Thanks Norbert for the good initiative. I am +1 on migrating to maven
>> I think it would be good to start with master branch. After changing and
>> stabilizing it, we can backport changes to other branches.
>> May be we can create an umbrella JIRA and create independent tasks under
>> it. There will be many things which can be handled independently
>>
>> Thanks & Regards
>> Arshad
>> -----Original Message-----
>> From: Enrico Olivelli [mailto:eolivelli@gmail.com]
>> Sent: Thursday, April 19, 2018 8:03 PM
>> To: DevZooKeeper <de...@zookeeper.apache.org>
>> Subject: Re: [SUGGESTION] Migrate project structure to Maven build
>>
>> Hi Norbert,
>> thank you for your suggestiion
>>
>> there is a long standing patch for migration to Maven
>> https://issues.apache.org/jira/browse/ZOOKEEPER-1078
>>
>> personally I am using that pom.xml in order to speed up work
>>
>> I really would like this change, but we need support from some committer.
>> It is an important change and it cannot be done without full consensus in
>> the community
>>
>> Cheers
>> Enrico
>>
>>
>> 2018-04-19 13:28 GMT+02:00 Norbert Kalmar <nk...@cloudera.com>:
>>
>> > Hi ZooKeeper community,
>> >
>> > As the vast majority of the components in the Hadoop ecosystem is
>> > built with Maven, what do you think of moving Zookeeper to a Maven
>> > structure as well?
>> >
>> > This would bring the benefit of a more consistent project structure,
>> > better dependency management and more possibilities for future changes
>> > (i.e.: we could separate java client code so that projects like HDFS
>> > that only needs the client doesn't have to import the whole ZooKeeper).
>> >
>> > This could be done as a multi-step change.
>> >
>> > The change would also include the separation of unit tests from
>> > integration and/or functional tests.
>> >
>> > In the first iteration, the project structure could be separated
>> > something
>> > like:
>> >
>> > zookeeper
>> > |-bin
>> > |-conf
>> > |-zk-client-c
>> > |-zk-contrib
>> > | |-zk-contrib-fatjar
>> > | |-zk-contrib-huebrowser
>> > | |-zk-contrib-loggraph
>> > | |-zk-contrib-monitoring
>> > | |-zk-contrib-rest
>> > | |-zk-contrib-zkfuse
>> > | |-zk-contrib-zkperl
>> > | |-zk-contrib-zkpython
>> > | |-zk-contrib-zktreeutil
>> > | \-zk-contrib-zooinspector
>> > |-zk-docs
>> > |-zk-it (integration tests)
>> > |-zk-server
>> > |-zk-recipes
>> > | |-zk-recipes-election
>> > | |-zk-recipes-lock
>> > \ \-zk-recipes-queue
>> >
>> >
>> > With this kind of structure, the code change could be kept to a bare
>> > minimum, if any at all.
>> > Just change the ant script to conform to the new structure.
>> >
>> > In a second iteration, we could start the changes that require code
>> > changes as well:
>> >
>> > zookeeper
>> > |-bin
>> > |-conf
>> > |-jute
>> > |-zk-client
>> > | |-zk-client-c
>> > | |-zk-client-java
>> > | \-zk-client-go (or any other language) -zk-common -zk-contrib
>> > | |-zk-contrib-fatjar
>> > | |-zk-contrib-huebrowser
>> > | |-zk-contrib-loggraph
>> > | |-zk-contrib-monitoring
>> > | |-zk-contrib-rest
>> > | |-zk-contrib-zkfuse
>> > | |-zk-contrib-zkperl
>> > | |-zk-contrib-zkpython
>> > | |-zk-contrib-zktreeutil
>> > | \-zk-contrib-zooinspector
>> > |-zk-docs
>> > |-zk-it (integration tests)
>> > |-zk-server
>> > |-zk-recipes
>> > | |-zk-recipes-election
>> > | |-zk-recipes-lock
>> > \ \-zk-recipes-queue
>> >
>> >
>> > Here, java client code is separated from the server code (and any
>> > other supported languages client code).
>> >
>> > The final iteration would be something like:
>> >
>> > zk-something
>> > |-src
>> > | |-main
>> > | |  |-java
>> > | |  | \org...
>> > | |   \resources
>> > | \test (unit tests only?)
>> > |  |-java
>> > |  |  \org...
>> > |  \resources
>> > \pom.xml
>> >
>> >
>> > But this is just to give a high level example/vision.
>> >
>> > Of course, with all the iteration, even at the end when possibly
>> > moving to a full Maven build, it is important that the final jar
>> > structure remains the same.
>> >
>> > What do you think?
>> >
>> > Kind regards,
>> > Norbert
>> >
>>
>
>

Re: [SUGGESTION] Migrate project structure to Maven build

Posted by Norbert Kalmar <nk...@cloudera.com>.
Hi All,

Thanks for the feedbacks.
@Enrico: I checked https://issues.apache.org/jira/browse/ZOOKEEPER-1078 .
It is very hard to keep track with the patch files, it should be committed.
But looking at the changes, it is more of a Maven proxy layer for ant with
lots of copy commands.

If we do change to maven, I think we should do so with getting rid of ant.
(Of course this will be one of the last steps). ZOOKEEPER-1078 approaches
the task to add support for Maven build via just a proxy layer over ant.

As @Mohammad mentiend, we could create an umbrella Jira, and start small
(or at least small in the sense of coda change/impact).

Looking at the reactions here, comments on ZOOKEEPER-1078 and other forums,
I think people would be positive to the change.

I will create the Umbrella Jira, so that we can start working on the first
steps, while waiting for other feedbacks.

Thanks,
Norbert

On Thu, Apr 19, 2018 at 2:53 PM, Ted Yu <yu...@gmail.com> wrote:

>  +1 for migrating to maven build.
> -------- Original message --------From: Mohammad arshad <
> mohammad.arshad@huawei.com> Date: 4/19/18  5:23 AM  (GMT-08:00) To:
> dev@zookeeper.apache.org Subject: RE: [SUGGESTION] Migrate project
> structure to Maven build
> Thanks Norbert for the good initiative. I am +1 on migrating to maven
> I think it would be good to start with master branch. After changing and
> stabilizing it, we can backport changes to other branches.
> May be we can create an umbrella JIRA and create independent tasks under
> it. There will be many things which can be handled independently
>
> Thanks & Regards
> Arshad
> -----Original Message-----
> From: Enrico Olivelli [mailto:eolivelli@gmail.com]
> Sent: Thursday, April 19, 2018 8:03 PM
> To: DevZooKeeper <de...@zookeeper.apache.org>
> Subject: Re: [SUGGESTION] Migrate project structure to Maven build
>
> Hi Norbert,
> thank you for your suggestiion
>
> there is a long standing patch for migration to Maven
> https://issues.apache.org/jira/browse/ZOOKEEPER-1078
>
> personally I am using that pom.xml in order to speed up work
>
> I really would like this change, but we need support from some committer.
> It is an important change and it cannot be done without full consensus in
> the community
>
> Cheers
> Enrico
>
>
> 2018-04-19 13:28 GMT+02:00 Norbert Kalmar <nk...@cloudera.com>:
>
> > Hi ZooKeeper community,
> >
> > As the vast majority of the components in the Hadoop ecosystem is
> > built with Maven, what do you think of moving Zookeeper to a Maven
> > structure as well?
> >
> > This would bring the benefit of a more consistent project structure,
> > better dependency management and more possibilities for future changes
> > (i.e.: we could separate java client code so that projects like HDFS
> > that only needs the client doesn't have to import the whole ZooKeeper).
> >
> > This could be done as a multi-step change.
> >
> > The change would also include the separation of unit tests from
> > integration and/or functional tests.
> >
> > In the first iteration, the project structure could be separated
> > something
> > like:
> >
> > zookeeper
> > |-bin
> > |-conf
> > |-zk-client-c
> > |-zk-contrib
> > | |-zk-contrib-fatjar
> > | |-zk-contrib-huebrowser
> > | |-zk-contrib-loggraph
> > | |-zk-contrib-monitoring
> > | |-zk-contrib-rest
> > | |-zk-contrib-zkfuse
> > | |-zk-contrib-zkperl
> > | |-zk-contrib-zkpython
> > | |-zk-contrib-zktreeutil
> > | \-zk-contrib-zooinspector
> > |-zk-docs
> > |-zk-it (integration tests)
> > |-zk-server
> > |-zk-recipes
> > | |-zk-recipes-election
> > | |-zk-recipes-lock
> > \ \-zk-recipes-queue
> >
> >
> > With this kind of structure, the code change could be kept to a bare
> > minimum, if any at all.
> > Just change the ant script to conform to the new structure.
> >
> > In a second iteration, we could start the changes that require code
> > changes as well:
> >
> > zookeeper
> > |-bin
> > |-conf
> > |-jute
> > |-zk-client
> > | |-zk-client-c
> > | |-zk-client-java
> > | \-zk-client-go (or any other language) -zk-common -zk-contrib
> > | |-zk-contrib-fatjar
> > | |-zk-contrib-huebrowser
> > | |-zk-contrib-loggraph
> > | |-zk-contrib-monitoring
> > | |-zk-contrib-rest
> > | |-zk-contrib-zkfuse
> > | |-zk-contrib-zkperl
> > | |-zk-contrib-zkpython
> > | |-zk-contrib-zktreeutil
> > | \-zk-contrib-zooinspector
> > |-zk-docs
> > |-zk-it (integration tests)
> > |-zk-server
> > |-zk-recipes
> > | |-zk-recipes-election
> > | |-zk-recipes-lock
> > \ \-zk-recipes-queue
> >
> >
> > Here, java client code is separated from the server code (and any
> > other supported languages client code).
> >
> > The final iteration would be something like:
> >
> > zk-something
> > |-src
> > | |-main
> > | |  |-java
> > | |  | \org...
> > | |   \resources
> > | \test (unit tests only?)
> > |  |-java
> > |  |  \org...
> > |  \resources
> > \pom.xml
> >
> >
> > But this is just to give a high level example/vision.
> >
> > Of course, with all the iteration, even at the end when possibly
> > moving to a full Maven build, it is important that the final jar
> > structure remains the same.
> >
> > What do you think?
> >
> > Kind regards,
> > Norbert
> >
>

RE: [SUGGESTION] Migrate project structure to Maven build

Posted by Ted Yu <yu...@gmail.com>.
 +1 for migrating to maven build.
-------- Original message --------From: Mohammad arshad <mo...@huawei.com> Date: 4/19/18  5:23 AM  (GMT-08:00) To: dev@zookeeper.apache.org Subject: RE: [SUGGESTION] Migrate project structure to Maven build 
Thanks Norbert for the good initiative. I am +1 on migrating to maven
I think it would be good to start with master branch. After changing and stabilizing it, we can backport changes to other branches.
May be we can create an umbrella JIRA and create independent tasks under it. There will be many things which can be handled independently

Thanks & Regards
Arshad
-----Original Message-----
From: Enrico Olivelli [mailto:eolivelli@gmail.com] 
Sent: Thursday, April 19, 2018 8:03 PM
To: DevZooKeeper <de...@zookeeper.apache.org>
Subject: Re: [SUGGESTION] Migrate project structure to Maven build

Hi Norbert,
thank you for your suggestiion

there is a long standing patch for migration to Maven
https://issues.apache.org/jira/browse/ZOOKEEPER-1078

personally I am using that pom.xml in order to speed up work

I really would like this change, but we need support from some committer.
It is an important change and it cannot be done without full consensus in the community

Cheers
Enrico


2018-04-19 13:28 GMT+02:00 Norbert Kalmar <nk...@cloudera.com>:

> Hi ZooKeeper community,
>
> As the vast majority of the components in the Hadoop ecosystem is 
> built with Maven, what do you think of moving Zookeeper to a Maven 
> structure as well?
>
> This would bring the benefit of a more consistent project structure, 
> better dependency management and more possibilities for future changes 
> (i.e.: we could separate java client code so that projects like HDFS 
> that only needs the client doesn't have to import the whole ZooKeeper).
>
> This could be done as a multi-step change.
>
> The change would also include the separation of unit tests from 
> integration and/or functional tests.
>
> In the first iteration, the project structure could be separated 
> something
> like:
>
> zookeeper
> |-bin
> |-conf
> |-zk-client-c
> |-zk-contrib
> | |-zk-contrib-fatjar
> | |-zk-contrib-huebrowser
> | |-zk-contrib-loggraph
> | |-zk-contrib-monitoring
> | |-zk-contrib-rest
> | |-zk-contrib-zkfuse
> | |-zk-contrib-zkperl
> | |-zk-contrib-zkpython
> | |-zk-contrib-zktreeutil
> | \-zk-contrib-zooinspector
> |-zk-docs
> |-zk-it (integration tests)
> |-zk-server
> |-zk-recipes
> | |-zk-recipes-election
> | |-zk-recipes-lock
> \ \-zk-recipes-queue
>
>
> With this kind of structure, the code change could be kept to a bare 
> minimum, if any at all.
> Just change the ant script to conform to the new structure.
>
> In a second iteration, we could start the changes that require code 
> changes as well:
>
> zookeeper
> |-bin
> |-conf
> |-jute
> |-zk-client
> | |-zk-client-c
> | |-zk-client-java
> | \-zk-client-go (or any other language) -zk-common -zk-contrib
> | |-zk-contrib-fatjar
> | |-zk-contrib-huebrowser
> | |-zk-contrib-loggraph
> | |-zk-contrib-monitoring
> | |-zk-contrib-rest
> | |-zk-contrib-zkfuse
> | |-zk-contrib-zkperl
> | |-zk-contrib-zkpython
> | |-zk-contrib-zktreeutil
> | \-zk-contrib-zooinspector
> |-zk-docs
> |-zk-it (integration tests)
> |-zk-server
> |-zk-recipes
> | |-zk-recipes-election
> | |-zk-recipes-lock
> \ \-zk-recipes-queue
>
>
> Here, java client code is separated from the server code (and any 
> other supported languages client code).
>
> The final iteration would be something like:
>
> zk-something
> |-src
> | |-main
> | |  |-java
> | |  | \org...
> | |   \resources
> | \test (unit tests only?)
> |  |-java
> |  |  \org...
> |  \resources
> \pom.xml
>
>
> But this is just to give a high level example/vision.
>
> Of course, with all the iteration, even at the end when possibly 
> moving to a full Maven build, it is important that the final jar 
> structure remains the same.
>
> What do you think?
>
> Kind regards,
> Norbert
>

RE: [SUGGESTION] Migrate project structure to Maven build

Posted by Mohammad arshad <mo...@huawei.com>.
Thanks Norbert for the good initiative. I am +1 on migrating to maven
I think it would be good to start with master branch. After changing and stabilizing it, we can backport changes to other branches.
May be we can create an umbrella JIRA and create independent tasks under it. There will be many things which can be handled independently

Thanks & Regards
Arshad
-----Original Message-----
From: Enrico Olivelli [mailto:eolivelli@gmail.com] 
Sent: Thursday, April 19, 2018 8:03 PM
To: DevZooKeeper <de...@zookeeper.apache.org>
Subject: Re: [SUGGESTION] Migrate project structure to Maven build

Hi Norbert,
thank you for your suggestiion

there is a long standing patch for migration to Maven
https://issues.apache.org/jira/browse/ZOOKEEPER-1078

personally I am using that pom.xml in order to speed up work

I really would like this change, but we need support from some committer.
It is an important change and it cannot be done without full consensus in the community

Cheers
Enrico


2018-04-19 13:28 GMT+02:00 Norbert Kalmar <nk...@cloudera.com>:

> Hi ZooKeeper community,
>
> As the vast majority of the components in the Hadoop ecosystem is 
> built with Maven, what do you think of moving Zookeeper to a Maven 
> structure as well?
>
> This would bring the benefit of a more consistent project structure, 
> better dependency management and more possibilities for future changes 
> (i.e.: we could separate java client code so that projects like HDFS 
> that only needs the client doesn't have to import the whole ZooKeeper).
>
> This could be done as a multi-step change.
>
> The change would also include the separation of unit tests from 
> integration and/or functional tests.
>
> In the first iteration, the project structure could be separated 
> something
> like:
>
> zookeeper
> |-bin
> |-conf
> |-zk-client-c
> |-zk-contrib
> | |-zk-contrib-fatjar
> | |-zk-contrib-huebrowser
> | |-zk-contrib-loggraph
> | |-zk-contrib-monitoring
> | |-zk-contrib-rest
> | |-zk-contrib-zkfuse
> | |-zk-contrib-zkperl
> | |-zk-contrib-zkpython
> | |-zk-contrib-zktreeutil
> | \-zk-contrib-zooinspector
> |-zk-docs
> |-zk-it (integration tests)
> |-zk-server
> |-zk-recipes
> | |-zk-recipes-election
> | |-zk-recipes-lock
> \ \-zk-recipes-queue
>
>
> With this kind of structure, the code change could be kept to a bare 
> minimum, if any at all.
> Just change the ant script to conform to the new structure.
>
> In a second iteration, we could start the changes that require code 
> changes as well:
>
> zookeeper
> |-bin
> |-conf
> |-jute
> |-zk-client
> | |-zk-client-c
> | |-zk-client-java
> | \-zk-client-go (or any other language) -zk-common -zk-contrib
> | |-zk-contrib-fatjar
> | |-zk-contrib-huebrowser
> | |-zk-contrib-loggraph
> | |-zk-contrib-monitoring
> | |-zk-contrib-rest
> | |-zk-contrib-zkfuse
> | |-zk-contrib-zkperl
> | |-zk-contrib-zkpython
> | |-zk-contrib-zktreeutil
> | \-zk-contrib-zooinspector
> |-zk-docs
> |-zk-it (integration tests)
> |-zk-server
> |-zk-recipes
> | |-zk-recipes-election
> | |-zk-recipes-lock
> \ \-zk-recipes-queue
>
>
> Here, java client code is separated from the server code (and any 
> other supported languages client code).
>
> The final iteration would be something like:
>
> zk-something
> |-src
> | |-main
> | |  |-java
> | |  | \org...
> | |   \resources
> | \test (unit tests only?)
> |  |-java
> |  |  \org...
> |  \resources
> \pom.xml
>
>
> But this is just to give a high level example/vision.
>
> Of course, with all the iteration, even at the end when possibly 
> moving to a full Maven build, it is important that the final jar 
> structure remains the same.
>
> What do you think?
>
> Kind regards,
> Norbert
>

Re: [SUGGESTION] Migrate project structure to Maven build

Posted by Enrico Olivelli <eo...@gmail.com>.
Hi Norbert,
thank you for your suggestiion

there is a long standing patch for migration to Maven
https://issues.apache.org/jira/browse/ZOOKEEPER-1078

personally I am using that pom.xml in order to speed up work

I really would like this change, but we need support from some committer.
It is an important change and it cannot be done without full consensus in
the community

Cheers
Enrico


2018-04-19 13:28 GMT+02:00 Norbert Kalmar <nk...@cloudera.com>:

> Hi ZooKeeper community,
>
> As the vast majority of the components in the Hadoop ecosystem is built
> with Maven, what do you think of moving Zookeeper to a Maven structure as
> well?
>
> This would bring the benefit of a more consistent project structure, better
> dependency management and more possibilities for future changes (i.e.: we
> could separate java client code so that projects like HDFS that only needs
> the client doesn't have to import the whole ZooKeeper).
>
> This could be done as a multi-step change.
>
> The change would also include the separation of unit tests from integration
> and/or functional tests.
>
> In the first iteration, the project structure could be separated something
> like:
>
> zookeeper
> |-bin
> |-conf
> |-zk-client-c
> |-zk-contrib
> | |-zk-contrib-fatjar
> | |-zk-contrib-huebrowser
> | |-zk-contrib-loggraph
> | |-zk-contrib-monitoring
> | |-zk-contrib-rest
> | |-zk-contrib-zkfuse
> | |-zk-contrib-zkperl
> | |-zk-contrib-zkpython
> | |-zk-contrib-zktreeutil
> | \-zk-contrib-zooinspector
> |-zk-docs
> |-zk-it (integration tests)
> |-zk-server
> |-zk-recipes
> | |-zk-recipes-election
> | |-zk-recipes-lock
> \ \-zk-recipes-queue
>
>
> With this kind of structure, the code change could be kept to a bare
> minimum, if any at all.
> Just change the ant script to conform to the new structure.
>
> In a second iteration, we could start the changes that require code changes
> as well:
>
> zookeeper
> |-bin
> |-conf
> |-jute
> |-zk-client
> | |-zk-client-c
> | |-zk-client-java
> | \-zk-client-go (or any other language)
> |-zk-common
> |-zk-contrib
> | |-zk-contrib-fatjar
> | |-zk-contrib-huebrowser
> | |-zk-contrib-loggraph
> | |-zk-contrib-monitoring
> | |-zk-contrib-rest
> | |-zk-contrib-zkfuse
> | |-zk-contrib-zkperl
> | |-zk-contrib-zkpython
> | |-zk-contrib-zktreeutil
> | \-zk-contrib-zooinspector
> |-zk-docs
> |-zk-it (integration tests)
> |-zk-server
> |-zk-recipes
> | |-zk-recipes-election
> | |-zk-recipes-lock
> \ \-zk-recipes-queue
>
>
> Here, java client code is separated from the server code (and any other
> supported languages client code).
>
> The final iteration would be something like:
>
> zk-something
> |-src
> | |-main
> | |  |-java
> | |  | \org...
> | |   \resources
> | \test (unit tests only?)
> |  |-java
> |  |  \org...
> |  \resources
> \pom.xml
>
>
> But this is just to give a high level example/vision.
>
> Of course, with all the iteration, even at the end when possibly moving to
> a full Maven build, it is important that the final jar structure remains
> the same.
>
> What do you think?
>
> Kind regards,
> Norbert
>