zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santosh Srinivas <sriniati...@gmail.com>
Subject Re: [SUGGESTION] Migrate project structure to Maven build
Date Sun, 22 Apr 2018 17:29:58 GMT
Hi Zookeeper community,

Nice suggestion Norbert. Without getting into the discussion of whether ant
or maven is a better build system we should chose a build mechanism that is
easier to maintain. Dependency management for big projects like zookeeper
can be quite a task and maven can help with its builtin dependency
management. Main benefit of ant is it does not impose any coding
conventions or project structures. I would like to know form the community
on any reasons to stick with Ant builds.


Best Regards,
Santosh.

On Sun, Apr 22, 2018 at 3:06 PM, 岭秀 <maoling199210191@sina.com> wrote:

> +1.
> It will be very,very useful,but a long way to go
> 1. Your roadmap of migrating to maven is thoughtful.It will be huge works
> to compatible with other plug-ins,dependency jars,systems just as ant did
> formerly?
> 2. In the process of migrating, how can we apply the new patch?
> ----- 原始邮件 -----
> 发件人:Norbert Kalmar <nkalmar@cloudera.com>
> 收件人:dev@zookeeper.apache.org
> 主题:[SUGGESTION] Migrate project structure to Maven build
> 日期:2018年04月19日 19点28分
>
> 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
>



-- 
Santosh Srinivas. V | salesforce.com, Hyderabad

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