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 <yuzhih...@gmail.com> wrote: > +1 for migrating to maven build. > -------- Original message --------From: Mohammad arshad < > mohammad.ars...@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:eolive...@gmail.com] > Sent: Thursday, April 19, 2018 8:03 PM > To: DevZooKeeper <dev@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 <nkal...@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 > > >
