ZooKeeper
  1. ZooKeeper
  2. ZOOKEEPER-103

Reorganize the ZooKeeper source distro to follow maven conventions

    Details

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

      Description

      This was sugested as way to bridge the gap in ZOOKEEPER-83

      1. ZOOKEEPER-103.patch
        8 kB
        Hiram Chirino
      2. ZOOKEEPER-103.sh
        1 kB
        Hiram Chirino

        Issue Links

          Activity

          Hide
          Hiram Chirino added a comment -

          This the shell script that will reorgnaize the source locations.

          Show
          Hiram Chirino added a comment - This the shell script that will reorgnaize the source locations.
          Hide
          Hiram Chirino added a comment -

          Attaching patch file for ant build so that it works using the new directory organization.

          Show
          Hiram Chirino added a comment - Attaching patch file for ant build so that it works using the new directory organization.
          Hide
          Patrick Hunt added a comment -

          What about additional contributions, they would be new directories at the same level (child of trunk)? trunk/zookeeper-recipes/..., trunk/zookeeper-spring/..., trunk/zookeeper-fuse/..., etc...?

          Show
          Patrick Hunt added a comment - What about additional contributions, they would be new directories at the same level (child of trunk)? trunk/zookeeper-recipes/..., trunk/zookeeper-spring/..., trunk/zookeeper-fuse/..., etc...?
          Hide
          Benjamin Reed added a comment -

          It would be nice to have a contrib directory to separate out what is mainline and what is not.

          Show
          Benjamin Reed added a comment - It would be nice to have a contrib directory to separate out what is mainline and what is not.
          Hide
          Hiram Chirino added a comment -

          Hi Patrick yes. Lots projects just keep it flat like that. Some project will group stuff in a directory if there is a specific grouping to the modules. Generally it's more specific than a general 'contrib' grouping though.

          Also something to think about is the possibility of having independent release cycles for some of the modules. At this stage of the I don't think we need to worry about that complexity.

          Benjamin,

          Generally the final binary distribution does make that distinction. Some organize as:
          /bin : start scripts
          /lib : the main zoo keeper jar
          /lib/extras or /lib/contrib: optional libs that are not required to run ZK
          /doc :
          /src

          etc. etc.

          Show
          Hiram Chirino added a comment - Hi Patrick yes. Lots projects just keep it flat like that. Some project will group stuff in a directory if there is a specific grouping to the modules. Generally it's more specific than a general 'contrib' grouping though. Also something to think about is the possibility of having independent release cycles for some of the modules. At this stage of the I don't think we need to worry about that complexity. Benjamin, Generally the final binary distribution does make that distinction. Some organize as: /bin : start scripts /lib : the main zoo keeper jar /lib/extras or /lib/contrib: optional libs that are not required to run ZK /doc : /src etc. etc.
          Hide
          Hiram Chirino added a comment -

          Any updates on this?

          Show
          Hiram Chirino added a comment - Any updates on this?
          Hide
          Mahadev konar added a comment -

          i like the new source tree structure — the only problem being that with contrib modules we will have lots of small contribs--- will they all have a top level directory?

          Show
          Mahadev konar added a comment - i like the new source tree structure — the only problem being that with contrib modules we will have lots of small contribs--- will they all have a top level directory?
          Hide
          Benjamin Reed added a comment -

          The hierachy implemented by this patch conflicts with ZOOKEEPER-80. Either the patch needs to accomodate the proposal in ZOOKEEPER-80, or ZOOKEEPER-80 needs to be updated with a new proposal.

          Show
          Benjamin Reed added a comment - The hierachy implemented by this patch conflicts with ZOOKEEPER-80 . Either the patch needs to accomodate the proposal in ZOOKEEPER-80 , or ZOOKEEPER-80 needs to be updated with a new proposal.
          Hide
          Hiram Chirino added a comment -

          Benjamin,

          Good point.. I'll comment on ZOOKEERER-80 on how best to sort out the recipies/contrib stuff.

          Show
          Hiram Chirino added a comment - Benjamin, Good point.. I'll comment on ZOOKEERER-80 on how best to sort out the recipies/contrib stuff.
          Hide
          Patrick Hunt added a comment -

          I reviewed the patch itself (the patch file and the script) against the code (this was on friday 7/25). It applied cleanly and the build/test continued to function properly.

          I'm a bit concerned that this new structure results in a large number of toplevel (trunk) directories... just me or anyone else think this might be an issue?

          Show
          Patrick Hunt added a comment - I reviewed the patch itself (the patch file and the script) against the code (this was on friday 7/25). It applied cleanly and the build/test continued to function properly. I'm a bit concerned that this new structure results in a large number of toplevel (trunk) directories... just me or anyone else think this might be an issue?
          Hide
          Hiram Chirino added a comment -

          Generally it's just a good sign showing that stuff is decoupled. we could group things into directories but that would just deepen the directory tree and not add tremendous amount of value.

          Show
          Hiram Chirino added a comment - Generally it's just a good sign showing that stuff is decoupled. we could group things into directories but that would just deepen the directory tree and not add tremendous amount of value.
          Hide
          Doug Cutting added a comment -

          > we could group things into directories but that would just deepen the directory tree and not add tremendous amount of value.

          I would prefer all sources under a single src/ directory, and not to have directories with redundant 'zookeeper-xxx' names. Separate subdirectories of trunk/src/ are no less decoupled than separate subdirectories of trunk/.

          Show
          Doug Cutting added a comment - > we could group things into directories but that would just deepen the directory tree and not add tremendous amount of value. I would prefer all sources under a single src/ directory, and not to have directories with redundant 'zookeeper-xxx' names. Separate subdirectories of trunk/src/ are no less decoupled than separate subdirectories of trunk/.
          Hide
          Hiram Chirino added a comment -

          The maven convention is to have each module/jar the it's own directory who's name matches the module/jar name.

          The ant build does not do this (yet) but in the maven build, you end up with zookeeper-xxx.jar files.

          Show
          Hiram Chirino added a comment - The maven convention is to have each module/jar the it's own directory who's name matches the module/jar name. The ant build does not do this (yet) but in the maven build, you end up with zookeeper-xxx.jar files.
          Hide
          Doug Cutting added a comment -

          > The maven convention is to have each module/jar the it's own directory who's name matches the module/jar name.

          That imposes big, redundant directory names. Is there no way to configure Maven otherwise?

          Show
          Doug Cutting added a comment - > The maven convention is to have each module/jar the it's own directory who's name matches the module/jar name. That imposes big, redundant directory names. Is there no way to configure Maven otherwise?
          Hide
          Hiram Chirino added a comment -

          The redundancy is a good convention since it makes it obvious which directory builds which jar file. And prefixing all the zookeeper jars with zookeeper- is a good convention too since it will help uniquely identify your jars in a project that uses multiple 3rd party jars. For example if ActiveMQ starts shipping some of the zookeeper bits in it's distribution.

          Show
          Hiram Chirino added a comment - The redundancy is a good convention since it makes it obvious which directory builds which jar file. And prefixing all the zookeeper jars with zookeeper- is a good convention too since it will help uniquely identify your jars in a project that uses multiple 3rd party jars. For example if ActiveMQ starts shipping some of the zookeeper bits in it's distribution.
          Hide
          Doug Cutting added a comment -

          You didn't answer my question: Is there a way to configure Maven otherwise?

          This issue looks suspiciously like trying to support two different build systems, and, on ZOOKEEPER-83, Pat said, "I'm -1 on supporting multiple build systems."

          Show
          Doug Cutting added a comment - You didn't answer my question: Is there a way to configure Maven otherwise? This issue looks suspiciously like trying to support two different build systems, and, on ZOOKEEPER-83 , Pat said, "I'm -1 on supporting multiple build systems."
          Hide
          Hiram Chirino added a comment -

          On ZOOKEEPER-83 we plainly agreed that we were going to compromise and use maven conventions for the directory structure but only include a ant build.

          And yes.. it's suspicious because it IS using the maven conventions. There is no doubt about it. That was part of the compromise.

          Show
          Hiram Chirino added a comment - On ZOOKEEPER-83 we plainly agreed that we were going to compromise and use maven conventions for the directory structure but only include a ant build. And yes.. it's suspicious because it IS using the maven conventions. There is no doubt about it. That was part of the compromise.
          Hide
          Doug Cutting added a comment -

          > On ZOOKEEPER-83 we plainly agreed that we were going to compromise and use maven conventions for the directory structure

          I don't see that. Pat & Nigel agreed that we should be able to produce Maven artifacts. Mahadev supported Maven naming conventions, but I don't see Pat reversing his -1 on supporting multiple build systems.

          Show
          Doug Cutting added a comment - > On ZOOKEEPER-83 we plainly agreed that we were going to compromise and use maven conventions for the directory structure I don't see that. Pat & Nigel agreed that we should be able to produce Maven artifacts. Mahadev supported Maven naming conventions, but I don't see Pat reversing his -1 on supporting multiple build systems.
          Hide
          Hiram Chirino added a comment -

          I think this patch is a nice middle ground. It's using only ANT, but adopting the maven directory conventions. So Pat's -1 does not really apply to this issue since ant is the only build system being used.

          Could the rest of the committers please post their thoughts on this?

          BTW once this is implemented, it should be easier to implement: ZOOKEEPER-95 and ZOOKEEPER-98

          Show
          Hiram Chirino added a comment - I think this patch is a nice middle ground. It's using only ANT, but adopting the maven directory conventions. So Pat's -1 does not really apply to this issue since ant is the only build system being used. Could the rest of the committers please post their thoughts on this? BTW once this is implemented, it should be easier to implement: ZOOKEEPER-95 and ZOOKEEPER-98
          Hide
          Benjamin Reed added a comment -

          I think we need to postpone this issue. It is causing a tremendous amount of distraction when we are right in the middle of getting out the next release. The proposal here conflicts with the proposal for maintaining recipes under contrib. It is also starting to hold up patches since the tree structure is considered in flux while this issue is open.

          In my opinion now is not the time for a tree restructuring. Lets focus on getting the patch backlog cleaned out and getting the release ready.

          Show
          Benjamin Reed added a comment - I think we need to postpone this issue. It is causing a tremendous amount of distraction when we are right in the middle of getting out the next release. The proposal here conflicts with the proposal for maintaining recipes under contrib. It is also starting to hold up patches since the tree structure is considered in flux while this issue is open. In my opinion now is not the time for a tree restructuring. Lets focus on getting the patch backlog cleaned out and getting the release ready.
          Hide
          Mahadev konar added a comment -

          +1 on ben's comments....
          the maven tree changes have caused considerable distraction for us and we havent been committing recipes just because of the maven changes.
          3.0 is an important release for us and we can keep this issue open while we work on the 3.0 release . We can be a little relaxed after we have 3.0 out the door and that will give us a chance to reflect and work on the directory structure with maven.

          Show
          Mahadev konar added a comment - +1 on ben's comments.... the maven tree changes have caused considerable distraction for us and we havent been committing recipes just because of the maven changes. 3.0 is an important release for us and we can keep this issue open while we work on the 3.0 release . We can be a little relaxed after we have 3.0 out the door and that will give us a chance to reflect and work on the directory structure with maven.
          Hide
          Mahadev konar added a comment -

          looking at the feedback. — cancelling patch for now. I will leave this open since we will re evaluate this in the future after 3.0 .

          Show
          Mahadev konar added a comment - looking at the feedback. — cancelling patch for now. I will leave this open since we will re evaluate this in the future after 3.0 .
          Hide
          Luca Telloli added a comment -

          Any update on this issue? I think it would be good to have at least zookeeper and related jars (like bookkeeper) in a maven repository for inclusion in projects that use maven or ivy for building

          Show
          Luca Telloli added a comment - Any update on this issue? I think it would be good to have at least zookeeper and related jars (like bookkeeper) in a maven repository for inclusion in projects that use maven or ivy for building

            People

            • Assignee:
              Hiram Chirino
              Reporter:
              Hiram Chirino
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:

                Development