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, 岭秀 <[email protected]> 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 <[email protected]> > 收件人：[email protected] > 主题：[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
