Seems like a bunch of tests are failing: testWithNamespace(org.apache.curator.framework.recipes.locks.TestInterProcessMultiMutex) testWithNamespace(org.apache.curator.framework.recipes.locks.TestInterProcessMutex) testWithNamespace(org.apache.curator.framework.recipes.locks.TestInterProcessSemaphoreMutex) testLockACLs(org.apache.curator.framework.recipes.locks.TestLockACLs) testSimulationWithLocksNamespace(org.apache.curator.framework.recipes.locks.TestReaper)
Tests are still running, and I haven't look into them yet, but it would seem based on the test names that something is broken with namespace stuff. Will have a look when I get a minute. cheers On Tue, Aug 18, 2015 at 1:38 PM, Scott Blum <dragonsi...@gmail.com> wrote: > Cool. You should be able to just push a fix and then fast-foward > CURATOR-3.0. > > On Mon, Aug 17, 2015 at 11:29 PM, Cameron McKenzie <mckenzie....@gmail.com > > wrote: > >> I think it's all good. I've fixed up the couple of build issues on the >> 217-merged branch. Just running the unit tests. If everything's ok then >> I'll merge it back into CURATOR-3.0 and then I think we're back in a stable >> state, and I can start on CURATOR-214. >> >> On Tue, Aug 18, 2015 at 1:27 PM, Scott Blum <dragonsi...@gmail.com> >> wrote: >> >>> I think just confirm that ZooDefs.CONFIG_NODE is the correct watcher >>> path for getConfig()? >>> >>> On Mon, Aug 17, 2015 at 11:19 PM, Jordan Zimmerman < >>> jor...@jordanzimmerman.com> wrote: >>> >>>> Sorry - it’s hard to follow this thread. What do I need to do? >>>> >>>> -Jordan >>>> >>>> >>>> >>>> On August 17, 2015 at 6:18:21 PM, Cameron McKenzie ( >>>> mckenzie....@gmail.com) wrote: >>>> >>>> Thanks Scott, >>>> I've just merged CURATOR-217 into master and have one small issue. >>>> >>>> Jordan, with the changes you made with to the Watching.java class, the >>>> getWatcher() call now takes a CuratorFramework reference and a path >>>> reference. >>>> >>>> The GetConfigBuilderImpl breaks when merging because it's using the old >>>> getWatcher() call that doesn't exist any more. This isn't an issue to >>>> fix, >>>> but I'm just wondering what path reference should be used for the >>>> configuration case, as it's a different sort of watch. It's just passed >>>> to >>>> the getConfig() call on the ZooKeeper class. It seems that I can't just >>>> pass in a null path as this gets validated. Suggestions? >>>> >>>> cheers >>>> >>>> >>>> On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman < >>>> jor...@jordanzimmerman.com> wrote: >>>> >>>> > Great work. Thank you. >>>> > >>>> > ==================== >>>> > Jordan Zimmerman >>>> > >>>> > > On Aug 17, 2015, at 12:10 PM, Scott Blum <dragonsi...@gmail.com> >>>> wrote: >>>> > > >>>> > > This is now done, sorry for the delay. Let me describe the current >>>> state >>>> > > of the world: >>>> > > >>>> > > CURATOR-215-original, CURATOR-160-original, CURATOR-3.0-old, >>>> > > CURATOR-3.0-temp - these are the old versions of all the branches, >>>> we >>>> > > should consider pruning them at some point. >>>> > > >>>> > > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are fixed/rebased >>>> versions >>>> > of >>>> > > the branches we should stick with. >>>> > > >>>> > > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.* There is >>>> nothing >>>> > > that has been committed to master that isn't in 3.0 now. >>>> > > >>>> > > Procedures going forward: >>>> > > >>>> > > - If you're working on stuff for 2.8 / 2.9, branch from master and >>>> > > merge/commit to master. >>>> > > >>>> > > - If you're working on stuff for 3.0, branch from CURATOR-3.0 and >>>> > > merge/commit to CURATOR-3.0. >>>> > > >>>> > > - Periodically, we'll want to get master changes into 3.0. To do >>>> this, >>>> > *check >>>> > > out CURATOR-3.0*, and merge master into that, then push the result >>>> after >>>> > > fixing conflicts (which should be small / non-existent). *Don't do >>>> it >>>> > the >>>> > > other way, don't check out master and merge 3.0 into it.* >>>> > > >>>> > > For discussion: there is a *3.0-rejects* branch. One of the commits >>>> > there >>>> > > is and added System.out.println that I think we don't want. The >>>> other >>>> > one >>>> > > is the work to migrate to fasterxml Jackson. I think we actually >>>> want >>>> > this >>>> > > commit on 3.0. Please take a look and let me know, if we want this >>>> > commit, >>>> > > we should cherry-pick it onto 3.0. I'm happy to do that. >>>> > > >>>> > > Everything I did should be reversible, so let me know if I screwed >>>> > anything >>>> > > up! >>>> > > >>>> > > --Scott >>>> > >>>> >>> >>> >> >
