zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norbert Kalmar <nkal...@cloudera.com>
Subject Re: [SUGGESTION] Migrate project structure to Maven build
Date Mon, 23 Apr 2018 11:12:03 GMT
Hi @maoling

To answer your questions:

1. Yes, we should strive to keep the current end artifact structure. The
end jar for example shouldn't change.
2. I think nothing really changes in this matter. If there are uncommitted
changes after some refactor, it will have to be rebased or resolved some
other way.

Regards,
Norbert

On Sun, Apr 22, 2018 at 7:29 PM, Santosh Srinivas <sriniatiisc@gmail.com>
wrote:

> 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