Details

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

      Description

      I've taken a stab at creating a maven build for ZooKeeper. (attachment to follow).

      1. ZOOKEEPER-1078.patch
        41 kB
        Patrick Hunt
      2. ZOOKEEPER-1078.patch
        41 kB
        Patrick Hunt
      3. ZOOKEEPER-1078.patch
        39 kB
        Patrick Hunt

        Issue Links

          Activity

          Hide
          Patrick Hunt added a comment -

          See the README_maven.txt and README.txt for background.

          Basically the patch adds
          1) maven support for the main app
          2) contrib/recipes/C are currently still built by ant/autotools. See the readme, but the basic idea is to move over to mvn slowly, incrementally, rather than one huge "refactor the world, oh and change the build system at the same time".
          3) ant/mvn will live side-by-side while we work out the kinks.
          4) I modeled things after Avro - specifically if you work on java you can use mvn, if you work on C you can use autotools, if you need to work with everything (say release manager) then you just "./build.sh dist;./build.sh sign" from the toplevel and publish as a release candidate.

          Summary of current status:
          everything builds, tests, and packages

          try running "./build.sh test" or follow the instructions to create an eclipse project that you can import into eclipse (notice that you get all the javadoc and source for dependencies!)

          eod this should be a win for developers, consumers (esp maven), something we can build on, and a HUGE win for release managers.

          there are still a few todos as listed in the readme. In particular the version generation is current turned off, it's hardcoded for now.

          Show
          Patrick Hunt added a comment - See the README_maven.txt and README.txt for background. Basically the patch adds 1) maven support for the main app 2) contrib/recipes/C are currently still built by ant/autotools. See the readme, but the basic idea is to move over to mvn slowly, incrementally, rather than one huge "refactor the world, oh and change the build system at the same time". 3) ant/mvn will live side-by-side while we work out the kinks. 4) I modeled things after Avro - specifically if you work on java you can use mvn, if you work on C you can use autotools, if you need to work with everything (say release manager) then you just "./build.sh dist;./build.sh sign" from the toplevel and publish as a release candidate. Summary of current status: everything builds, tests, and packages try running "./build.sh test" or follow the instructions to create an eclipse project that you can import into eclipse (notice that you get all the javadoc and source for dependencies!) eod this should be a win for developers, consumers (esp maven), something we can build on, and a HUGE win for release managers. there are still a few todos as listed in the readme. In particular the version generation is current turned off, it's hardcoded for now.
          Hide
          Patrick Hunt added a comment -

          Note (esp committer): you need to chmod +x the build.sh and src/c/build.sh when trying this out (the build scripts, you don't need to worry if you are just "mvn test" or something).

          Btw, this patch has NO requirements that we change the current file/directory hierarchy. I did this on purpose to ease us into supporting maven. Over time we would remove ant support once everyone is comfortable with the new build and all the kinks are worked out, jenkins builds are working, etc... I managed this via some hacks in the pom file that we will eventually remove. In order to do so we will need to make "svn move" changes at that time. However that should be fairly simple and not effect things like blame and such. Again, see the readme for more details.

          MORE IMPORTANT: I also think we should try and move to Maven before the 3.4.0 release. Here's why. 3.3.x is very stable, there are limited amounts of backported patches that we're going to need to do. So we can hack on 3.4.0 w/o worrying about the pain of backporting due to filesystem moves. Say we wait till after 3.4.0, we'll likely be doing a number of fixes on 3.4, if trunk and 3.4 are significantly different (filesystem structure) we're going to have alot more pain. That's my thinking at least. Feel free to comment.

          Show
          Patrick Hunt added a comment - Note (esp committer): you need to chmod +x the build.sh and src/c/build.sh when trying this out (the build scripts, you don't need to worry if you are just "mvn test" or something). Btw, this patch has NO requirements that we change the current file/directory hierarchy. I did this on purpose to ease us into supporting maven. Over time we would remove ant support once everyone is comfortable with the new build and all the kinks are worked out, jenkins builds are working, etc... I managed this via some hacks in the pom file that we will eventually remove. In order to do so we will need to make "svn move" changes at that time. However that should be fairly simple and not effect things like blame and such. Again, see the readme for more details. MORE IMPORTANT: I also think we should try and move to Maven before the 3.4.0 release. Here's why. 3.3.x is very stable, there are limited amounts of backported patches that we're going to need to do. So we can hack on 3.4.0 w/o worrying about the pain of backporting due to filesystem moves. Say we wait till after 3.4.0, we'll likely be doing a number of fixes on 3.4, if trunk and 3.4 are significantly different (filesystem structure) we're going to have alot more pain. That's my thinking at least. Feel free to comment.
          Hide
          Henry Robinson added a comment -

          +1 - source builds, tests run, pom.xml looks fine to me (although I'm not a maven aesthete).

          Patrick, you haven't added any new dependencies, right? So we don't need to worry about licensing with any new deps getting pulled in.

          Show
          Henry Robinson added a comment - +1 - source builds, tests run, pom.xml looks fine to me (although I'm not a maven aesthete). Patrick, you haven't added any new dependencies, right? So we don't need to worry about licensing with any new deps getting pulled in.
          Hide
          Patrick Hunt added a comment -

          Good question. No, I don't think so. Although the dependency resolution is different so we should verify....

          Btw, this is one of the great things about maven!!

          $ mvn dependency:list
          [INFO] Scanning for projects...
          [INFO]                                                                         
          [INFO] ------------------------------------------------------------------------
          [INFO] Building ZooKeeper 3.4.0-SNAPSHOT
          [INFO] ------------------------------------------------------------------------
          [INFO] 
          [INFO] --- maven-dependency-plugin:2.1:list (default-cli) @ zookeeper ---
          [INFO] 
          [INFO] The following files have been resolved:
          [INFO]    asm:asm:jar:3.1:test
          [INFO]    asm:asm-analysis:jar:3.1:test
          [INFO]    asm:asm-commons:jar:3.1:test
          [INFO]    asm:asm-tree:jar:3.1:test
          [INFO]    asm:asm-util:jar:3.1:test
          [INFO]    asm:asm-xml:jar:3.1:test
          [INFO]    com.google.code.findbugs:annotations:jar:1.3.9:test
          [INFO]    com.google.code.findbugs:bcel:jar:1.3.9:test
          [INFO]    com.google.code.findbugs:findbugs:jar:1.3.9:test
          [INFO]    com.google.code.findbugs:jFormatString:jar:1.3.9:test
          [INFO]    com.google.code.findbugs:jsr305:jar:1.3.9:test
          [INFO]    com.ibm.icu:icu4j:jar:2.6.1:test
          [INFO]    com.j2speed.accessor:accessive:jar:1.1:system
          [INFO]    commons-lang:commons-lang:jar:2.4:test
          [INFO]    dom4j:dom4j:jar:1.6.1:test
          [INFO]    jaxen:jaxen:jar:1.1.1:test
          [INFO]    jdom:jdom:jar:1.0:test
          [INFO]    jline:jline:jar:0.9.94:compile
          [INFO]    junit:junit:jar:4.8.1:test
          [INFO]    log4j:log4j:jar:1.2.16:compile
          [INFO]    org.hamcrest:hamcrest-all:jar:1.1:test
          [INFO]    org.jboss.netty:netty:jar:3.2.4.Final:compile
          [INFO]    org.mockito:mockito-all:jar:1.8.5:test
          [INFO]    org.slf4j:slf4j-api:jar:1.6.1:compile
          [INFO]    org.slf4j:slf4j-log4j12:jar:1.6.1:compile
          [INFO]    xalan:xalan:jar:2.6.0:test
          [INFO]    xerces:xmlParserAPIs:jar:2.6.2:test
          [INFO]    xml-apis:xml-apis:jar:1.0.b2:test
          [INFO]    xom:xom:jar:1.0:test
          [INFO] 
          [INFO] ------------------------------------------------------------------------
          [INFO] BUILD SUCCESS
          [INFO] ------------------------------------------------------------------------
          [INFO] Total time: 2.730s
          [INFO] Finished at: Tue Jun 21 15:39:33 PDT 2011
          [INFO] Final Memory: 9M/131M
          [INFO] ------------------------------------------------------------------------
          

          Notice that much of this is "test", only the usual suspects show up under system/compile. (netty/slf4j being new in 3.4)

          Show
          Patrick Hunt added a comment - Good question. No, I don't think so. Although the dependency resolution is different so we should verify.... Btw, this is one of the great things about maven!! $ mvn dependency:list [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building ZooKeeper 3.4.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-dependency-plugin:2.1:list (default-cli) @ zookeeper --- [INFO] [INFO] The following files have been resolved: [INFO] asm:asm:jar:3.1:test [INFO] asm:asm-analysis:jar:3.1:test [INFO] asm:asm-commons:jar:3.1:test [INFO] asm:asm-tree:jar:3.1:test [INFO] asm:asm-util:jar:3.1:test [INFO] asm:asm-xml:jar:3.1:test [INFO] com.google.code.findbugs:annotations:jar:1.3.9:test [INFO] com.google.code.findbugs:bcel:jar:1.3.9:test [INFO] com.google.code.findbugs:findbugs:jar:1.3.9:test [INFO] com.google.code.findbugs:jFormatString:jar:1.3.9:test [INFO] com.google.code.findbugs:jsr305:jar:1.3.9:test [INFO] com.ibm.icu:icu4j:jar:2.6.1:test [INFO] com.j2speed.accessor:accessive:jar:1.1:system [INFO] commons-lang:commons-lang:jar:2.4:test [INFO] dom4j:dom4j:jar:1.6.1:test [INFO] jaxen:jaxen:jar:1.1.1:test [INFO] jdom:jdom:jar:1.0:test [INFO] jline:jline:jar:0.9.94:compile [INFO] junit:junit:jar:4.8.1:test [INFO] log4j:log4j:jar:1.2.16:compile [INFO] org.hamcrest:hamcrest-all:jar:1.1:test [INFO] org.jboss.netty:netty:jar:3.2.4.Final:compile [INFO] org.mockito:mockito-all:jar:1.8.5:test [INFO] org.slf4j:slf4j-api:jar:1.6.1:compile [INFO] org.slf4j:slf4j-log4j12:jar:1.6.1:compile [INFO] xalan:xalan:jar:2.6.0:test [INFO] xerces:xmlParserAPIs:jar:2.6.2:test [INFO] xml-apis:xml-apis:jar:1.0.b2:test [INFO] xom:xom:jar:1.0:test [INFO] [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 2.730s [INFO] Finished at: Tue Jun 21 15:39:33 PDT 2011 [INFO] Final Memory: 9M/131M [INFO] ------------------------------------------------------------------------ Notice that much of this is "test", only the usual suspects show up under system/compile. (netty/slf4j being new in 3.4)
          Hide
          Eric Charles added a comment -

          I applied the patch on trunk r1141932, and was able to 'mvn install -DskipTests=true' (tests took too much time).
          It also builds fine when importing in eclipse via m2eclipse.

          The non-test scope dependencies are also here:
          [INFO] jline:jline:jar:0.9.94:compile
          [INFO] log4j:log4j:jar:1.2.16:compile
          [INFO] org.jboss.netty:netty:jar:3.2.4.Final:compile
          [INFO] org.slf4j:slf4j-api:jar:1.6.1:compile
          [INFO] org.slf4j:slf4j-log4j12:jar:1.6.1:compile
          [INFO] com.j2speed.accessor:accessive:jar:1.1:system

          About the tests, I am now waiting on o.a.z.t.QuorumZxidSyncTest.
          There is <forkedProcessTimeoutInSeconds>10800</forkedProcessTimeoutInSeconds>, which is 3 hours.
          Is such a long timeout really needed for some tests?

          Show
          Eric Charles added a comment - I applied the patch on trunk r1141932, and was able to 'mvn install -DskipTests=true' (tests took too much time). It also builds fine when importing in eclipse via m2eclipse. The non-test scope dependencies are also here: [INFO] jline:jline:jar:0.9.94:compile [INFO] log4j:log4j:jar:1.2.16:compile [INFO] org.jboss.netty:netty:jar:3.2.4.Final:compile [INFO] org.slf4j:slf4j-api:jar:1.6.1:compile [INFO] org.slf4j:slf4j-log4j12:jar:1.6.1:compile [INFO] com.j2speed.accessor:accessive:jar:1.1:system About the tests, I am now waiting on o.a.z.t.QuorumZxidSyncTest. There is <forkedProcessTimeoutInSeconds>10800</forkedProcessTimeoutInSeconds>, which is 3 hours. Is such a long timeout really needed for some tests?
          Hide
          Patrick Hunt added a comment -

          probably not, notice I cut it way down from what's in ant but I felt that 3 hours was fine (this typically is never hit). I suppose I could cut it down further... afaik the tests take around 30minutes to run everything...

          Show
          Patrick Hunt added a comment - probably not, notice I cut it way down from what's in ant but I felt that 3 hours was fine (this typically is never hit). I suppose I could cut it down further... afaik the tests take around 30minutes to run everything...
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12480606/ZOOKEEPER-1078.patch
          against trunk revision 1148553.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 24 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

          -1 release audit. The applied patch generated 30 release audit warnings (more than the trunk's current 24 warnings).

          +1 core tests. The patch passed core unit tests.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/403//testReport/
          Release audit warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/403//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
          Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/403//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/403//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12480606/ZOOKEEPER-1078.patch against trunk revision 1148553. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 24 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. -1 release audit. The applied patch generated 30 release audit warnings (more than the trunk's current 24 warnings). +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/403//testReport/ Release audit warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/403//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/403//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/403//console This message is automatically generated.
          Hide
          Patrick Hunt added a comment -

          Henry has given a +1 on this, so I'm going to commit it myself to 3.5.0 (trunk) unless there are objections.

          Show
          Patrick Hunt added a comment - Henry has given a +1 on this, so I'm going to commit it myself to 3.5.0 (trunk) unless there are objections.
          Hide
          Eric Yang added a comment -

          -1 (non-binding), This patch will break the packaging code for rpm/deb packages. It would be nice if those features are retained.

          Show
          Eric Yang added a comment - -1 (non-binding), This patch will break the packaging code for rpm/deb packages. It would be nice if those features are retained.
          Hide
          Thomas Koch added a comment -

          -1 (not a committer): The build process becomes very complicate with the current proposed patch. There's build.sh calling pom.xml calling build.xml... Couldn't we do it the other way round? Refactor the current ant build to match as close as possible a maven project and then do the switch?
          Why not do the svn moves right now? People could use GIT to update existing patches to a new directory layout.
          We could also make ant call maven for those things that are easily done by maven and thus fading out ant step by step.

          Show
          Thomas Koch added a comment - -1 (not a committer): The build process becomes very complicate with the current proposed patch. There's build.sh calling pom.xml calling build.xml... Couldn't we do it the other way round? Refactor the current ant build to match as close as possible a maven project and then do the switch? Why not do the svn moves right now? People could use GIT to update existing patches to a new directory layout. We could also make ant call maven for those things that are easily done by maven and thus fading out ant step by step.
          Hide
          Patrick Hunt added a comment -

          Need to update the patch to address 899/96 (I'm working on it).

          Show
          Patrick Hunt added a comment - Need to update the patch to address 899/96 (I'm working on it).
          Hide
          Patrick Hunt added a comment -

          updates for latest trunk. I'll commit this soon if there are no objections.

          Show
          Patrick Hunt added a comment - updates for latest trunk. I'll commit this soon if there are no objections.
          Hide
          Eric Yang added a comment -

          Patrick, is it possible to build rpm/deb package with the new maven structure?
          For generate signature, I would recommend to wrap it in maven deploy or install phase of a profile. It would be nice to optimize maven profiles to remove the need of build.sh.

          Show
          Eric Yang added a comment - Patrick, is it possible to build rpm/deb package with the new maven structure? For generate signature, I would recommend to wrap it in maven deploy or install phase of a profile. It would be nice to optimize maven profiles to remove the need of build.sh.
          Hide
          Patrick Hunt added a comment -

          This first effort was before packaging support, so I've never looked at it from the maven side of things. It would be great if you could try it out and LMK (ie submit follow-on patches). I am not a pkging expert so really I have no idea. My expectation is that we (zk) build a release artifact, which is the "source" release. That source release can be built in many ways, including running something that will generate pkgs.

          That said, I haven't changed anything in svn that effects the ant build side of things. I took special care to implement maven so that it can sit aside ant build without requiring changes to ant itself. So you should still be able to ant build everything and then generate the pkgs from that. Keep in mind that this patch, ie mvn build, is currently a subset of the ant build functionality.

          Show
          Patrick Hunt added a comment - This first effort was before packaging support, so I've never looked at it from the maven side of things. It would be great if you could try it out and LMK (ie submit follow-on patches). I am not a pkging expert so really I have no idea. My expectation is that we (zk) build a release artifact, which is the "source" release. That source release can be built in many ways, including running something that will generate pkgs. That said, I haven't changed anything in svn that effects the ant build side of things. I took special care to implement maven so that it can sit aside ant build without requiring changes to ant itself. So you should still be able to ant build everything and then generate the pkgs from that. Keep in mind that this patch, ie mvn build, is currently a subset of the ant build functionality.
          Hide
          Patrick Hunt added a comment -

          For generate signature, I would recommend to wrap it in maven deploy or install phase of a profile. It would be nice to optimize maven profiles to remove the need of build.sh.

          right, forgot to mention. this patch is currently a subset, I suspect over time we'll remove the need for build.sh (or at least limit it, given we do need to build both java and c clients, etc... Also contrib/recipes is not mvn supported yet, I haven't quite figured out that part yet. We'll also add a bunch of new functionality, ideas such as you mention sound like reasonable things to do. Keep in mind I'm doing this incrementally to limit disruption to the community.

          Show
          Patrick Hunt added a comment - For generate signature, I would recommend to wrap it in maven deploy or install phase of a profile. It would be nice to optimize maven profiles to remove the need of build.sh. right, forgot to mention. this patch is currently a subset, I suspect over time we'll remove the need for build.sh (or at least limit it, given we do need to build both java and c clients, etc... Also contrib/recipes is not mvn supported yet, I haven't quite figured out that part yet. We'll also add a bunch of new functionality, ideas such as you mention sound like reasonable things to do. Keep in mind I'm doing this incrementally to limit disruption to the community.
          Hide
          Patrick Hunt added a comment -

          Updated the patch against the latest trunk.

          Show
          Patrick Hunt added a comment - Updated the patch against the latest trunk.
          Hide
          Patrick Hunt added a comment -

          Missed Thomas's previous comment - no svn moves right now given we want to maintain b/w compat while switching over. build.sh is a bit more complicated but as I said previously we'll remove that when possible. The key right now its to maintain the ant compatibility until mvn works, then drop ant when everyone is confident, then make bigger changes such as hierarchy.

          Show
          Patrick Hunt added a comment - Missed Thomas's previous comment - no svn moves right now given we want to maintain b/w compat while switching over. build.sh is a bit more complicated but as I said previously we'll remove that when possible. The key right now its to maintain the ant compatibility until mvn works, then drop ant when everyone is confident, then make bigger changes such as hierarchy.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12508444/ZOOKEEPER-1078.patch
          against trunk revision 1221868.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 24 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

          -1 release audit. The applied patch generated 28 release audit warnings (more than the trunk's current 24 warnings).

          -1 core tests. The patch failed core unit tests.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/853//testReport/
          Release audit warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/853//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
          Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/853//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/853//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12508444/ZOOKEEPER-1078.patch against trunk revision 1221868. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 24 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. -1 release audit. The applied patch generated 28 release audit warnings (more than the trunk's current 24 warnings). -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/853//testReport/ Release audit warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/853//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/853//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/853//console This message is automatically generated.
          Hide
          Jean-Baptiste Onofré added a comment -

          Updating pom.xml introducing commons-cli for build and maven-bundle-plugin to generate the OSGi statements.

          Show
          Jean-Baptiste Onofré added a comment - Updating pom.xml introducing commons-cli for build and maven-bundle-plugin to generate the OSGi statements.
          Hide
          Jean-Baptiste Onofré added a comment -

          I forked on my github to work on Maven and OSGi change:

          https://github.com/jbonofre/zookeeper

          I fixed the maven-bundle-plugin instructions.

          Now, I'm starting:

          • Karaf features
          • Karaf command
          • a URL handler (which will allow cat zk:/ in Karaf shell for instance)
          • extension in Karaf console
          Show
          Jean-Baptiste Onofré added a comment - I forked on my github to work on Maven and OSGi change: https://github.com/jbonofre/zookeeper I fixed the maven-bundle-plugin instructions. Now, I'm starting: Karaf features Karaf command a URL handler (which will allow cat zk:/ in Karaf shell for instance) extension in Karaf console
          Hide
          Michi Mutsuzaki added a comment -

          This patch doesn't apply anymore. Pat, could you update the patch when you get a chance?

          Thanks!
          --Michi

          Show
          Michi Mutsuzaki added a comment - This patch doesn't apply anymore. Pat, could you update the patch when you get a chance? Thanks! --Michi
          Hide
          Patrick Hunt added a comment -

          I can do that, but do we want to include this in 3.5.0? Include could be as optional (secondary) to the ant build, or a full replacement for build.xml. I think at this point we might want to wait for 3.6? (if that's the case I wouldn't bother updating it right now, it will just get out of sync)

          It would be good to have some f/b from folks. Moving to maven would make our lives easier in some respects, but there might be some short term pain involved...

          Show
          Patrick Hunt added a comment - I can do that, but do we want to include this in 3.5.0? Include could be as optional (secondary) to the ant build, or a full replacement for build.xml. I think at this point we might want to wait for 3.6? (if that's the case I wouldn't bother updating it right now, it will just get out of sync) It would be good to have some f/b from folks. Moving to maven would make our lives easier in some respects, but there might be some short term pain involved...
          Hide
          Michi Mutsuzaki added a comment -

          I'm ok with pushing this out to 3.6.

          Show
          Michi Mutsuzaki added a comment - I'm ok with pushing this out to 3.6.

            People

            • Assignee:
              Patrick Hunt
              Reporter:
              Patrick Hunt
            • Votes:
              3 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:

                Development