ZooKeeper
  1. ZooKeeper
  2. ZOOKEEPER-83

Switch to using maven to build ZooKeeper

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: build
    • Labels:
      None

      Description

      Maven is a great too for building java projects at the ASF. It helps standardize the build a bit since it's a convention oriented.
      It's dependency auto downloading would remove the need to store the dependencies in svn, and it will handle many of the suggested ASF policies like gpg signing of the releases and such.

      The ZooKeeper build is almost vanilla except for the jute compiler bits. Things that would need to change are:

      • re-organize the source tree a little so that it uses the maven directory conventions
      • seperate the jute bits out into seperate modules so that a maven plugin can be with it

        Activity

        Hide
        Michi Mutsuzaki added a comment -

        The work to migrate from ant to maven is tracked here:

        https://issues.apache.org/jira/browse/ZOOKEEPER-1078

        The current plan is to migrate to maven after releasing 3.5.0.

        Show
        Michi Mutsuzaki added a comment - The work to migrate from ant to maven is tracked here: https://issues.apache.org/jira/browse/ZOOKEEPER-1078 The current plan is to migrate to maven after releasing 3.5.0.
        Hide
        Edward Ribeiro added a comment -

        IMO, yes. It would be very nice to have Maven as ZooKeeper build tool, in addition (or replacing) Ant. OTOH, from the date of this jira ticket creation, I assume it's not something as easy to do as one would think at first.

        Show
        Edward Ribeiro added a comment - IMO, yes. It would be very nice to have Maven as ZooKeeper build tool, in addition (or replacing) Ant. OTOH, from the date of this jira ticket creation, I assume it's not something as easy to do as one would think at first.
        Hide
        Killua Huang added a comment -

        So far, maven is a poplar and powerful way to build Java project. As Zookeeper development, is it necessary to use maven to build ZK?

        This jira ticket was created in 2008 and still open.

        Show
        Killua Huang added a comment - So far, maven is a poplar and powerful way to build Java project. As Zookeeper development, is it necessary to use maven to build ZK? This jira ticket was created in 2008 and still open.
        Hide
        Hiram Chirino added a comment -

        I've created a maven plugin that can be used to verify integrity of downloaded dependencies. This should cross out the biggest concern that the hadoop folks had with maven. The plugin can be found here:

        https://svn.apache.org/repos/asf/servicemix/maven-plugins/checksum-maven-plugin/trunk

        Show
        Hiram Chirino added a comment - I've created a maven plugin that can be used to verify integrity of downloaded dependencies. This should cross out the biggest concern that the hadoop folks had with maven. The plugin can be found here: https://svn.apache.org/repos/asf/servicemix/maven-plugins/checksum-maven-plugin/trunk
        Hide
        Hiram Chirino added a comment -

        FYI: The maven folks are working on the security issue:
        http://docs.codehaus.org/display/MAVEN/Repository+Security

        Show
        Hiram Chirino added a comment - FYI: The maven folks are working on the security issue: http://docs.codehaus.org/display/MAVEN/Repository+Security
        Hide
        Patrick Hunt added a comment -

        Some additional background: similar request on hadoop core with list of pro/con HADOOP-3302

        Show
        Patrick Hunt added a comment - Some additional background: similar request on hadoop core with list of pro/con HADOOP-3302
        Hide
        Mahadev konar added a comment -

        are we going to close this one then ?

        Show
        Mahadev konar added a comment - are we going to close this one then ?
        Hide
        Hiram Chirino added a comment -

        Re-opened as a new issue ZOOKEEPER-103
        it reduces the scope of the patch to just be implementing the maven directory conventions.

        Show
        Hiram Chirino added a comment - Re-opened as a new issue ZOOKEEPER-103 it reduces the scope of the patch to just be implementing the maven directory conventions.
        Hide
        Patrick Hunt added a comment -

        Removed from patch available status: the changes need to be attached as a patch file. (or patch file + script if things need to be moved around a lot as it seems in this case).

        Show
        Patrick Hunt added a comment - Removed from patch available status: the changes need to be attached as a patch file. (or patch file + script if things need to be moved around a lot as it seems in this case).
        Hide
        Patrick Hunt added a comment -

        When I pinged Nigel earlier we got our wires crossed, I understood ASF Hudson to not support Maven (I know Hudson in general does), but after my comment he pinged me back saying that it does - it's an option when you initially create but doesn't show up on configure page (if you select ant rather than maven) which further lead to my confusion.

        Sorry, my bad

        Show
        Patrick Hunt added a comment - When I pinged Nigel earlier we got our wires crossed, I understood ASF Hudson to not support Maven (I know Hudson in general does), but after my comment he pinged me back saying that it does - it's an option when you initially create but doesn't show up on configure page (if you select ant rather than maven) which further lead to my confusion. Sorry, my bad
        Hide
        Mahadev konar added a comment -

        i like the idea. +1 for maven directory convention and no maven build files and using ant ..

        Show
        Mahadev konar added a comment - i like the idea. +1 for maven directory convention and no maven build files and using ant ..
        Hide
        Nigel Daley added a comment -

        +1 for staying with Ant and creating maven artifacts.

        Show
        Nigel Daley added a comment - +1 for staying with Ant and creating maven artifacts.
        Hide
        james strachan added a comment -
        Show
        james strachan added a comment - Hudson does support Maven and Ant natively http://hudson.gotdns.com/wiki/display/HUDSON/Plugins#Plugins-Buildtools
        Hide
        Hiram Chirino added a comment -
        Show
        Hiram Chirino added a comment - BTW Hudson does support maven.. see: http://weblogs.java.net/blog/kohsuke/archive/2007/02/maven_2_integra.html
        Hide
        Hiram Chirino added a comment -

        BTW there are lots of CI tools used at the ASF which DO support maven. But hey if you like Hudson that's cool.

        Can we at least merge the patch in so that the maven directory convention is preserved and then we can delete the maven build files if you like. The ant build can work with that structure just fine. If we do that then I can provide folks who are interested in a maven build the pom files that just overlay onto the project do they can use maven to build it.

        So we both win. ZooKeeper only has 1 build system ant. Maven users also win cause they can get some optional poms from me to build the project with. What do you think?

        Show
        Hiram Chirino added a comment - BTW there are lots of CI tools used at the ASF which DO support maven. But hey if you like Hudson that's cool. Can we at least merge the patch in so that the maven directory convention is preserved and then we can delete the maven build files if you like. The ant build can work with that structure just fine. If we do that then I can provide folks who are interested in a maven build the pom files that just overlay onto the project do they can use maven to build it. So we both win. ZooKeeper only has 1 build system ant. Maven users also win cause they can get some optional poms from me to build the project with. What do you think?
        Hide
        Patrick Hunt added a comment -

        ASF Hudson, our CI for ZooKeeper, does not support Maven:
        http://hudson.zones.apache.org/hudson/view/ZooKeeper/

        I'm -1 on supporting multiple build systems.

        +1 for having zookeeper jars in the maven repository (I suggest someone create a new JIRA for this as it's orthogonal to the build tool)

        Show
        Patrick Hunt added a comment - ASF Hudson, our CI for ZooKeeper, does not support Maven: http://hudson.zones.apache.org/hudson/view/ZooKeeper/ I'm -1 on supporting multiple build systems. +1 for having zookeeper jars in the maven repository (I suggest someone create a new JIRA for this as it's orthogonal to the build tool)
        Hide
        Hiram Chirino added a comment - - edited

        Hi folks..

        To make the maven re-org super simple to apply I created a temp private branch so that the changes can easily be merged into trunk.
        This branch also has an updated ant build which works with the new maven directory structure.

        To merge the changes back into trunk, just run the follow in a clean trunk checkout:

        svn merge -r 679094:679134 https://svn.apache.org/repos/asf/activemq/sandbox/zookeeper
        
        Show
        Hiram Chirino added a comment - - edited Hi folks.. To make the maven re-org super simple to apply I created a temp private branch so that the changes can easily be merged into trunk. This branch also has an updated ant build which works with the new maven directory structure. To merge the changes back into trunk, just run the follow in a clean trunk checkout: svn merge -r 679094:679134 https: //svn.apache.org/repos/asf/activemq/sandbox/zookeeper
        Hide
        Doug Cutting added a comment -

        > I believe there is a way to use ANT to create Maven modules for the repository right?

        Yes. This is what, e.g., Lucene does.

        http://svn.apache.org/repos/asf/lucene/java/trunk/build.xml
        http://svn.apache.org/repos/asf/lucene/java/trunk/common-build.xml

        Show
        Doug Cutting added a comment - > I believe there is a way to use ANT to create Maven modules for the repository right? Yes. This is what, e.g., Lucene does. http://svn.apache.org/repos/asf/lucene/java/trunk/build.xml http://svn.apache.org/repos/asf/lucene/java/trunk/common-build.xml
        Hide
        james strachan added a comment -

        So long as dependencies don't change much and the build process doesn't undergo any major radical changes, its not gonna require much in the way of maintenance keeping the maven build going. (BTW Maven can auto-generate an Ant build too which uses the Maven ant tasks to work with dependencies and repos). Am sure Hiram or myself would happily keep the maven build ticking along. So its zero overhead to the ZK team.

        In terms of Ivy; yeah I've heard it can work with maven repos; but I've never worked on a project that really uses it - it just seams much easier if you wanna work with maven metadata, dependencies, hierarchical projects and repositories to just use Maven . There's a zillion issues with keeping your metadata up to date on compile/optional/test dependencies and dealing with hierarchial projects and transitive dependency issues - so I've no idea what issues you'd run into using Ivy - over the years we've bumped into a zillion issues with Maven so I certainly understand the maven resistence. Everyone has a love/hate relationship with it - until you try to re-implement what it does in Ant and you end up with some kinda grudging respect for it . (Especially if you ever have to do any OSGi work!)

        But sure if you guys wanna figure out the Ivy route so it'd be easy to build, test and install the ZK jars into a local or remote Maven repo, I'd be really happy! Given both Hiram and myself have been really heavy Maven users for many years (after being heavy Ant users before then) I doubt you'll be getting any Ant+Ivy patches for the build system from either of us though .

        Heck if the Maven build only lives around until someone figures out how to replace it with Ant+Ivy I think we'd all be happy; so starting with a maven build then replacing it later if someone can figure out how to do it with Ant+Ivy sounds a reasonable approach. (And we could always keep the maven build ticking along until the Ant+Ivy approach really does work).

        Show
        james strachan added a comment - So long as dependencies don't change much and the build process doesn't undergo any major radical changes, its not gonna require much in the way of maintenance keeping the maven build going. (BTW Maven can auto-generate an Ant build too which uses the Maven ant tasks to work with dependencies and repos). Am sure Hiram or myself would happily keep the maven build ticking along. So its zero overhead to the ZK team. In terms of Ivy; yeah I've heard it can work with maven repos; but I've never worked on a project that really uses it - it just seams much easier if you wanna work with maven metadata, dependencies, hierarchical projects and repositories to just use Maven . There's a zillion issues with keeping your metadata up to date on compile/optional/test dependencies and dealing with hierarchial projects and transitive dependency issues - so I've no idea what issues you'd run into using Ivy - over the years we've bumped into a zillion issues with Maven so I certainly understand the maven resistence. Everyone has a love/hate relationship with it - until you try to re-implement what it does in Ant and you end up with some kinda grudging respect for it . (Especially if you ever have to do any OSGi work!) But sure if you guys wanna figure out the Ivy route so it'd be easy to build, test and install the ZK jars into a local or remote Maven repo, I'd be really happy! Given both Hiram and myself have been really heavy Maven users for many years (after being heavy Ant users before then) I doubt you'll be getting any Ant+Ivy patches for the build system from either of us though . Heck if the Maven build only lives around until someone figures out how to replace it with Ant+Ivy I think we'd all be happy; so starting with a maven build then replacing it later if someone can figure out how to do it with Ant+Ivy sounds a reasonable approach. (And we could always keep the maven build ticking along until the Ant+Ivy approach really does work).
        Hide
        Benjamin Reed added a comment -

        I completely agreed with the goals you are expressing. Having ZooKeeper in the Maven repository is a good thing all the way around.

        The problem I have is supporting two different build tools. Granted we have a patch now, but going forward we would have to maintain (meaning fixing the build scripts and running the tests) both. I think that one build tool makes everyones life sane (er).

        I'm not familiar with most projects, but Hadoop (who we are a subproject of) doesn't use Maven. I talked to Owen about Hadoop using Maven and he mentioned they were looking at Ivy. I also see that there are Maven ant tasks from the Maven project that we can use. It seems to me that least disruptive way to get into the Maven repository is to use either the ant tasks or Ivy.

        Do you guys have an opinion on either of those two routes?

        Show
        Benjamin Reed added a comment - I completely agreed with the goals you are expressing. Having ZooKeeper in the Maven repository is a good thing all the way around. The problem I have is supporting two different build tools. Granted we have a patch now, but going forward we would have to maintain (meaning fixing the build scripts and running the tests) both. I think that one build tool makes everyones life sane (er). I'm not familiar with most projects, but Hadoop (who we are a subproject of) doesn't use Maven. I talked to Owen about Hadoop using Maven and he mentioned they were looking at Ivy. I also see that there are Maven ant tasks from the Maven project that we can use. It seems to me that least disruptive way to get into the Maven repository is to use either the ant tasks or Ivy. Do you guys have an opinion on either of those two routes?
        Hide
        Hiram Chirino added a comment -

        James is right.

        An ant build could easily co-exist with the maven one if folks feel that adverse to maven.

        Show
        Hiram Chirino added a comment - James is right. An ant build could easily co-exist with the maven one if folks feel that adverse to maven.
        Hide
        james strachan added a comment -

        Note its pretty trivial to maintain an Ant build as well as a Maven build if folks really have an aversion to Maven. There's really no reason at all to disallow a maven build from being created; they can both happily coexist - and its also a pretty trivial bit of work - not some huge bit of R&D thats gonna slow down development on other things. Also note that a non committer has already contributed the patch already for you - so no more work is required other than committing it

        Its worth remembering that pretty much all popular Java software at Apache is now released into a Maven repository...
        http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/

        so if folks stick with Ant and refuse to allow a maven build to coexist with the Ant build, someone should volunteer to figure out how to hack the Ant build to release ZooKeeper into the Apache maven repository - otherwise its pretty hard for folks who do use maven to reuse your code (and see from the repo how many Apache projects we're talking about not being able to easily reuse ZooKeeper).

        i.e. as part of the move to the ASF and being a good Apache citizen, I'd recommend hugely that as a minimum ZooKeeper releases its jars into the Apache Maven repository like most other projects do.

        The easiest way to do this is just to reuse a Maven build to do releases (there doesn't yet seem to be anything in the Ant build to do actual signed releases or deploy builds anywhere) - and let folks who prefer Ant to stick to that for day to day development.

        The easier it is to reuse a project, the more likely it'll get used and the more likely you'll get contributions; at least thats my experience at Apache. That doesn't mean you have to force your Ant-loving developers to switch build tools!

        Show
        james strachan added a comment - Note its pretty trivial to maintain an Ant build as well as a Maven build if folks really have an aversion to Maven. There's really no reason at all to disallow a maven build from being created; they can both happily coexist - and its also a pretty trivial bit of work - not some huge bit of R&D thats gonna slow down development on other things. Also note that a non committer has already contributed the patch already for you - so no more work is required other than committing it Its worth remembering that pretty much all popular Java software at Apache is now released into a Maven repository... http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/ so if folks stick with Ant and refuse to allow a maven build to coexist with the Ant build, someone should volunteer to figure out how to hack the Ant build to release ZooKeeper into the Apache maven repository - otherwise its pretty hard for folks who do use maven to reuse your code (and see from the repo how many Apache projects we're talking about not being able to easily reuse ZooKeeper). i.e. as part of the move to the ASF and being a good Apache citizen, I'd recommend hugely that as a minimum ZooKeeper releases its jars into the Apache Maven repository like most other projects do. The easiest way to do this is just to reuse a Maven build to do releases (there doesn't yet seem to be anything in the Ant build to do actual signed releases or deploy builds anywhere) - and let folks who prefer Ant to stick to that for day to day development. The easier it is to reuse a project, the more likely it'll get used and the more likely you'll get contributions; at least thats my experience at Apache. That doesn't mean you have to force your Ant-loving developers to switch build tools!
        Hide
        Patrick Hunt added a comment -

        Regardless of whether this is a good idea or not we should consider whether it's a good idea right now. We are currently working towards 4 goals (in order or priority):

        1) support/expand our user & contributor base
        2) complete migration to ASF
        3) 3.0 version of ZooKeeper
        and just added recently
        4) recipe implementation (which is a good thing IMO and also supports 1 above)

        Given the current build system is functioning fine I personally think we should post-pone decisions like this and continue to work towards the goals listed above. There's more than enough work to go around w/o creating new.

        ps:

        I've added Roadmap and ProjectSuggestions pages to the ZooKeeper wiki. Pretty bare right now but I can tell you that tests (refactoring our current client/server test infrastructure in particular - see ZOOKEEPER-61) and documentation need alot of work. Don't hesitate to contact me or any of the other committers if you'd like to take on an existing Jira issue slated for 3.0 or would like to be assigned something.

        Show
        Patrick Hunt added a comment - Regardless of whether this is a good idea or not we should consider whether it's a good idea right now . We are currently working towards 4 goals (in order or priority): 1) support/expand our user & contributor base 2) complete migration to ASF 3) 3.0 version of ZooKeeper and just added recently 4) recipe implementation (which is a good thing IMO and also supports 1 above) Given the current build system is functioning fine I personally think we should post-pone decisions like this and continue to work towards the goals listed above. There's more than enough work to go around w/o creating new. ps: I've added Roadmap and ProjectSuggestions pages to the ZooKeeper wiki. Pretty bare right now but I can tell you that tests (refactoring our current client/server test infrastructure in particular - see ZOOKEEPER-61 ) and documentation need alot of work. Don't hesitate to contact me or any of the other committers if you'd like to take on an existing Jira issue slated for 3.0 or would like to be assigned something.
        Hide
        Benjamin Reed added a comment -

        I think it might be good to separate out the issues here. Two of them I see are: 1) Use Maven instead of ANT to build because Maven is so much better. 2) Make it so that ZooKeeper can be added to a Maven repository.

        I'm not really convinced about 1), but 2) seems like a cool thing. I believe there is a way to use ANT to create Maven modules for the repository right?

        Show
        Benjamin Reed added a comment - I think it might be good to separate out the issues here. Two of them I see are: 1) Use Maven instead of ANT to build because Maven is so much better. 2) Make it so that ZooKeeper can be added to a Maven repository. I'm not really convinced about 1), but 2) seems like a cool thing. I believe there is a way to use ANT to create Maven modules for the repository right?
        Hide
        Mahadev konar added a comment -

        i agree with Doug on this. We never felt a need for maven since our code base is not huge and we are all familiar with ant and we havent had any problems with ant yet.

        Show
        Mahadev konar added a comment - i agree with Doug on this. We never felt a need for maven since our code base is not huge and we are all familiar with ant and we havent had any problems with ant yet.
        Hide
        Doug Cutting added a comment -

        > Is that the only issue?

        I think its fundamentally a cultural issue. We have developers here who are familiar with Ant and have developed processes around Ant and are not frustrated with Ant and see no need to switch to a different build system. It's a bit like git versus svn: git may be better, but not enough folks yet feel that svn is a significant bottleneck, perhaps through ignorance. I still use Emacs, despite folks telling me I should use an IDE.

        If the majority of Zookeeper's community want to switch to Maven, I would certainly not oppose it.

        Show
        Doug Cutting added a comment - > Is that the only issue? I think its fundamentally a cultural issue. We have developers here who are familiar with Ant and have developed processes around Ant and are not frustrated with Ant and see no need to switch to a different build system. It's a bit like git versus svn: git may be better, but not enough folks yet feel that svn is a significant bottleneck, perhaps through ignorance. I still use Emacs, despite folks telling me I should use an IDE. If the majority of Zookeeper's community want to switch to Maven, I would certainly not oppose it.
        Hide
        Hiram Chirino added a comment -

        Sure.. maven is not yet impervious to having it's repository hacked. But does it actually happen? No.

        But then again any repository can get hacked.. even the one we deploy our distributions to. Yes we sign the releases, but how often do folks actually validate against it? So in most systems that kind of attack will happen.

        Is that the only issue?

        Show
        Hiram Chirino added a comment - Sure.. maven is not yet impervious to having it's repository hacked. But does it actually happen? No. But then again any repository can get hacked.. even the one we deploy our distributions to. Yes we sign the releases, but how often do folks actually validate against it? So in most systems that kind of attack will happen. Is that the only issue?
        Hide
        Doug Cutting added a comment -
        Show
        Doug Cutting added a comment - Love of Maven is not universal. http://www.mail-archive.com/general@incubator.apache.org/msg18295.html
        Hide
        Hiram Chirino added a comment -

        Flavio,

        maven provides a much more standardize build process than ant. Any maven java project has the same directory structure and build/release procedure. Therefore new contributors who are familiar with maven will be more comfortable contributing to ZooKeeper because of it.

        It handles lots of the wonky ASF relase rules like:

        • GPG sighing
        • staging release artifacts to get voted on.
        • building binary distros with api docs
        • building source distros
        • including and verifying LICENSE and NOTICE files are in all jars
        • It can run the rat tool for you to verify that all source files have the right headers on them

        It encourages folks to use your project

        • It deploys your jar artifacts to a centralized maven repository where other projects can automatically pull your libs into their builds.
        • the maven repo is a sort of eco system, where if your artifacts are available in it, folks are more willing to use your stuff, and they in turn pubish artifacts the depend on ZooKeeper which in turn might get used by someone else who transitively gets ZooKeeper
        • It encourages good release patterns like including the version number in the jar. Nice to have so that when folks use your jars it is obvious what version they are using.

        It encourages good modularization/decoupling:

        • It's easy to add additional jars to the project and then add dependencies between them. This encourage folks to decouple their code properly.
        • Once you have a nicely modular project, it easy for folks to add additional optional modules for new features. For example I could see folks wanting a zookeeper-spring module.

        Plus it does lots of useful things like:

        • generate IDE project files so that they don't need to be manually maintained.
        • it can enforce checkstyle rules if desired
        • Runs findbugs and cobertura
        • It can creates great set of cross indexed html docs about the build including

        Plus since it's declarative in a nature, folks can use other maven plugins against the build (without changing the build files) to access additional interesting features.

        Maven in general is more higher level concept than ANT. It brings power and flexibility to the table. Plus it's the direction most new java projects are taking these days.

        So I think the question really is why keep ANT?

        Show
        Hiram Chirino added a comment - Flavio, maven provides a much more standardize build process than ant. Any maven java project has the same directory structure and build/release procedure. Therefore new contributors who are familiar with maven will be more comfortable contributing to ZooKeeper because of it. It handles lots of the wonky ASF relase rules like: GPG sighing staging release artifacts to get voted on. building binary distros with api docs building source distros including and verifying LICENSE and NOTICE files are in all jars It can run the rat tool for you to verify that all source files have the right headers on them It encourages folks to use your project It deploys your jar artifacts to a centralized maven repository where other projects can automatically pull your libs into their builds. the maven repo is a sort of eco system, where if your artifacts are available in it, folks are more willing to use your stuff, and they in turn pubish artifacts the depend on ZooKeeper which in turn might get used by someone else who transitively gets ZooKeeper It encourages good release patterns like including the version number in the jar. Nice to have so that when folks use your jars it is obvious what version they are using. It encourages good modularization/decoupling: It's easy to add additional jars to the project and then add dependencies between them. This encourage folks to decouple their code properly. Once you have a nicely modular project, it easy for folks to add additional optional modules for new features. For example I could see folks wanting a zookeeper-spring module. Plus it does lots of useful things like: generate IDE project files so that they don't need to be manually maintained. it can enforce checkstyle rules if desired Runs findbugs and cobertura It can creates great set of cross indexed html docs about the build including Plus since it's declarative in a nature, folks can use other maven plugins against the build (without changing the build files) to access additional interesting features. Maven in general is more higher level concept than ANT. It brings power and flexibility to the table. Plus it's the direction most new java projects are taking these days. So I think the question really is why keep ANT?
        Hide
        Hiram Chirino added a comment -

        James, I think you missed it but, the build dues include a module to create a uber-jar, look at the zookeeper-all module. This creates a jar with all the runtime dependencies needed to run a zookeeper server (yes this includes log4j).

        Show
        Hiram Chirino added a comment - James, I think you missed it but, the build dues include a module to create a uber-jar, look at the zookeeper-all module. This creates a jar with all the runtime dependencies needed to run a zookeeper server (yes this includes log4j).
        Hide
        Hiram Chirino added a comment -

        Besides the re-organization of the directory structures, I added a couple Mojo.java files for to create the maven plugins for the source code generation bits. And I modified the jute and version gen stuff so that you can specify an output directory.

        Also several files got deleted like all the jar files in the lib dir, and the checked in javacc generated files since maven is now running javacc to generate them from the .jj file.

        Show
        Hiram Chirino added a comment - Besides the re-organization of the directory structures, I added a couple Mojo.java files for to create the maven plugins for the source code generation bits. And I modified the jute and version gen stuff so that you can specify an output directory. Also several files got deleted like all the jar files in the lib dir, and the checked in javacc generated files since maven is now running javacc to generate them from the .jj file.
        Hide
        Flavio Junqueira added a comment -

        I remember we had a discussion right when we moved ZooKeeper to sourceforge about moving to maven, and we ended up agreeing not to do it. I'm happy to retake the discussion, but as I don't fully understand all the implications of moving to maven, it would be useful to me to understand what we gain and what we lose by doing it.

        Show
        Flavio Junqueira added a comment - I remember we had a discussion right when we moved ZooKeeper to sourceforge about moving to maven, and we ended up agreeing not to do it. I'm happy to retake the discussion, but as I don't fully understand all the implications of moving to maven, it would be useful to me to understand what we gain and what we lose by doing it.
        Hide
        james strachan added a comment -

        I just took a look at the patch; basically the maven conventions are to put source in $

        {module-name}/src/main/java and tests in ${module-name}

        /src/test/java and resources in src/main/resources etc.

        Plus it looks like hiram's split the project into multiple maven modules. (e.g. so that the Java 6 JMX code is a separate module so that the core of zookeeper can be used on Java 5 - which is a good thing IMHO - plus separating the jute stuff so it can be used in development time to generate code etc). Its also easy to generate an uber-jar if folks want later on.

        This patch looks good to me - assuming folks are happy to go the maven route (which many other apache projects do btw - it certainly makes it much easier for zookeeper to be reused by other maven projects).

        If this patch gets applied I'll happily volunteer to refactor my recipes/protocols patch to create a zookeeper-protocols module to create a separate jar for higher level stuff

        Show
        james strachan added a comment - I just took a look at the patch; basically the maven conventions are to put source in $ {module-name}/src/main/java and tests in ${module-name} /src/test/java and resources in src/main/resources etc. Plus it looks like hiram's split the project into multiple maven modules. (e.g. so that the Java 6 JMX code is a separate module so that the core of zookeeper can be used on Java 5 - which is a good thing IMHO - plus separating the jute stuff so it can be used in development time to generate code etc). Its also easy to generate an uber-jar if folks want later on. This patch looks good to me - assuming folks are happy to go the maven route (which many other apache projects do btw - it certainly makes it much easier for zookeeper to be reused by other maven projects). If this patch gets applied I'll happily volunteer to refactor my recipes/protocols patch to create a zookeeper-protocols module to create a separate jar for higher level stuff
        Hide
        Mahadev konar added a comment -

        hiram, can you list an overall set of changes you had to make to make the src tree maven compatible. It would help with people who do not want to download the tgz to see what the changes are.

        Show
        Mahadev konar added a comment - hiram, can you list an overall set of changes you had to make to make the src tree maven compatible. It would help with people who do not want to download the tgz to see what the changes are.
        Hide
        Hiram Chirino added a comment -

        I just attached a mavenized version of ZooKeeper based on rev 677371

        I would have provided a patch, but due to the directory re-organizations, it would be too hard to produce and apply. So attached is a full source distro, please evaluate and comment. Hopefully if folks like it, it can be used as a guide.

        For folks who are new to maven, here is a quick guide:

        to build: mvn install
        to clean mvn clean
        to clean build: mvn clean install

        to skip tests during a build: mvn install -Dtest=false
        to create eclipse project files: mvn eclipse:eclipse
        to create intelij projects files: mvn idea:idea

        Show
        Hiram Chirino added a comment - I just attached a mavenized version of ZooKeeper based on rev 677371 I would have provided a patch, but due to the directory re-organizations, it would be too hard to produce and apply. So attached is a full source distro, please evaluate and comment. Hopefully if folks like it, it can be used as a guide. For folks who are new to maven, here is a quick guide: to build: mvn install to clean mvn clean to clean build: mvn clean install to skip tests during a build: mvn install -Dtest=false to create eclipse project files: mvn eclipse:eclipse to create intelij projects files: mvn idea:idea

          People

          • Assignee:
            Hiram Chirino
            Reporter:
            Hiram Chirino
          • Votes:
            4 Vote for this issue
            Watchers:
            10 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development