Re: Contrib section (nee Re: A modest proposal for simplifying zookeeper :)
just to be clear: i'm not a maven fan, but i'm not sure anything else is better. buildr looks better flexibility wise, but i think maven is much more popular and mature. with ivy we are still stuck with ant build files. ben Patrick Hunt wrote: Ben, you might want to look at buildr, it recently graduated from the apache incubator: http://buildr.apache.org/ "Buildr is a build system for Java applications. We wanted something that’s simple and intuitive to use, so we only need to tell it what to do, and it takes care of the rest. But also something we can easily extend for those one-off tasks, with a language that’s a joy to use. And of course, we wanted it to be fast, reliable and have outstanding dependency management." Also Ivy just released version 2.0. If you have a specific idea and would like to start working on this please create a JIRA to discuss/track/vote/etc... Be aware that the contribution process, release process and other documentation would have to be updated as part of this. For example if we want to push jars to an artifact repo the artifacts/pom/etc... would have to be voted on as part of the release process. Patrick Benjamin Reed wrote: i'm ready to reevaluate it. i did the contrib for fatjar and it was extremely painful! (and that was an extremely simple contrib!) we really want to ramp up the contribs and get a bunch of recipe implementations in, so we need something that makes it really easy. i'm not a fan of maven (they seem to have chosen a convention that is convenient for the build tool rather the developer), but it is widely used and i we need something better, so i'm certainly considering it. ben Anthony Urso wrote: Speaking of the contrib section, what is the status of ZOOKEEPER-103? Is it ready to be reevaluated now that 3.0 is out? Cheers, Anthony On Fri, Jan 9, 2009 at 11:58 AM, Mahadev Konar wrote: Hi Kevin, It would be great to have such high level interfaces. It could be something that you could contribute :) . We havent had the bandwidth to provide such interfaces for zookeeper. It would be great to have all such recipes as a part of contrib package of zookeeper. mahadev On 1/9/09 11:44 AM, "Kevin Burton" wrote: OK so it sounds from the group that there are still reasons to provide rope in ZK to enable algorithms like leader election. Couldn't ZK ship higher level interfaces for leader election, mutexes, semapores, queues, barriers, etc instead of pushing this on developers? Then the remaining APIs, configuration, event notification, and discovery, can be used on a simpler, rope free API. The rope is what's killing me now :) Kevin
Re: Contrib section (nee Re: A modest proposal for simplifying zookeeper :)
Ben, you might want to look at buildr, it recently graduated from the apache incubator: http://buildr.apache.org/ "Buildr is a build system for Java applications. We wanted something that’s simple and intuitive to use, so we only need to tell it what to do, and it takes care of the rest. But also something we can easily extend for those one-off tasks, with a language that’s a joy to use. And of course, we wanted it to be fast, reliable and have outstanding dependency management." Also Ivy just released version 2.0. If you have a specific idea and would like to start working on this please create a JIRA to discuss/track/vote/etc... Be aware that the contribution process, release process and other documentation would have to be updated as part of this. For example if we want to push jars to an artifact repo the artifacts/pom/etc... would have to be voted on as part of the release process. Patrick Benjamin Reed wrote: i'm ready to reevaluate it. i did the contrib for fatjar and it was extremely painful! (and that was an extremely simple contrib!) we really want to ramp up the contribs and get a bunch of recipe implementations in, so we need something that makes it really easy. i'm not a fan of maven (they seem to have chosen a convention that is convenient for the build tool rather the developer), but it is widely used and i we need something better, so i'm certainly considering it. ben Anthony Urso wrote: Speaking of the contrib section, what is the status of ZOOKEEPER-103? Is it ready to be reevaluated now that 3.0 is out? Cheers, Anthony On Fri, Jan 9, 2009 at 11:58 AM, Mahadev Konar wrote: Hi Kevin, It would be great to have such high level interfaces. It could be something that you could contribute :) . We havent had the bandwidth to provide such interfaces for zookeeper. It would be great to have all such recipes as a part of contrib package of zookeeper. mahadev On 1/9/09 11:44 AM, "Kevin Burton" wrote: OK so it sounds from the group that there are still reasons to provide rope in ZK to enable algorithms like leader election. Couldn't ZK ship higher level interfaces for leader election, mutexes, semapores, queues, barriers, etc instead of pushing this on developers? Then the remaining APIs, configuration, event notification, and discovery, can be used on a simpler, rope free API. The rope is what's killing me now :) Kevin
Re: Contrib section (nee Re: A modest proposal for simplifying zookeeper :)
i'm ready to reevaluate it. i did the contrib for fatjar and it was extremely painful! (and that was an extremely simple contrib!) we really want to ramp up the contribs and get a bunch of recipe implementations in, so we need something that makes it really easy. i'm not a fan of maven (they seem to have chosen a convention that is convenient for the build tool rather the developer), but it is widely used and i we need something better, so i'm certainly considering it. ben Anthony Urso wrote: Speaking of the contrib section, what is the status of ZOOKEEPER-103? Is it ready to be reevaluated now that 3.0 is out? Cheers, Anthony On Fri, Jan 9, 2009 at 11:58 AM, Mahadev Konar wrote: Hi Kevin, It would be great to have such high level interfaces. It could be something that you could contribute :) . We havent had the bandwidth to provide such interfaces for zookeeper. It would be great to have all such recipes as a part of contrib package of zookeeper. mahadev On 1/9/09 11:44 AM, "Kevin Burton" wrote: OK so it sounds from the group that there are still reasons to provide rope in ZK to enable algorithms like leader election. Couldn't ZK ship higher level interfaces for leader election, mutexes, semapores, queues, barriers, etc instead of pushing this on developers? Then the remaining APIs, configuration, event notification, and discovery, can be used on a simpler, rope free API. The rope is what's killing me now :) Kevin
Re: Contrib section (nee Re: A modest proposal for simplifying zookeeper :)
Hi Anthony. We have a contrib in the current release, it's under src. I'm not sure I understand, what is "contrib section" referring to? Or do you mean client recipe implementations? (like ZOOKEEPER-78, which is being worked on for 3.2) Patrick Anthony Urso wrote: So does this mean no contrib section? On Thu, Feb 26, 2009 at 10:00 PM, Patrick Hunt wrote: So far we've stayed with the process used by core as this minimizes the amount of work we need to do re process/build/release, etc... we just copy the process/build/release etc... used in core, we get all that for free. I'm hesitant to diverge as this will increase the amount of work we need to do. Core has moved to Ivy, we may move to that at some point, but currently we're focused on adding functionality, fixing bugs -- not changing build. Patrick Anthony Urso wrote: Speaking of the contrib section, what is the status of ZOOKEEPER-103? Is it ready to be reevaluated now that 3.0 is out? Cheers, Anthony On Fri, Jan 9, 2009 at 11:58 AM, Mahadev Konar wrote: Hi Kevin, It would be great to have such high level interfaces. It could be something that you could contribute :) . We havent had the bandwidth to provide such interfaces for zookeeper. It would be great to have all such recipes as a part of contrib package of zookeeper. mahadev On 1/9/09 11:44 AM, "Kevin Burton" wrote: OK so it sounds from the group that there are still reasons to provide rope in ZK to enable algorithms like leader election. Couldn't ZK ship higher level interfaces for leader election, mutexes, semapores, queues, barriers, etc instead of pushing this on developers? Then the remaining APIs, configuration, event notification, and discovery, can be used on a simpler, rope free API. The rope is what's killing me now :) Kevin
Re: Contrib section (nee Re: A modest proposal for simplifying zookeeper :)
So does this mean no contrib section? On Thu, Feb 26, 2009 at 10:00 PM, Patrick Hunt wrote: > So far we've stayed with the process used by core as this minimizes the > amount of work we need to do re process/build/release, etc... we just copy > the process/build/release etc... used in core, we get all that for free. I'm > hesitant to diverge as this will increase the amount of work we need to do. > Core has moved to Ivy, we may move to that at some point, but currently > we're focused on adding functionality, fixing bugs -- not changing build. > > Patrick > > Anthony Urso wrote: >> >> Speaking of the contrib section, what is the status of ZOOKEEPER-103? >> Is it ready to be reevaluated now that 3.0 is out? >> >> Cheers, >> Anthony >> >> On Fri, Jan 9, 2009 at 11:58 AM, Mahadev Konar >> wrote: >>> >>> Hi Kevin, >>> It would be great to have such high level interfaces. It could be >>> something that you could contribute :) . We havent had the bandwidth to >>> provide such interfaces for zookeeper. It would be great to have all such >>> recipes as a part of contrib package of zookeeper. >>> >>> mahadev >>> >>> On 1/9/09 11:44 AM, "Kevin Burton" wrote: >>> OK so it sounds from the group that there are still reasons to provide rope in ZK to enable algorithms like leader election. Couldn't ZK ship higher level interfaces for leader election, mutexes, semapores, queues, barriers, etc instead of pushing this on developers? Then the remaining APIs, configuration, event notification, and discovery, can be used on a simpler, rope free API. The rope is what's killing me now :) Kevin >>> >
Re: Contrib section (nee Re: A modest proposal for simplifying zookeeper :)
So far we've stayed with the process used by core as this minimizes the amount of work we need to do re process/build/release, etc... we just copy the process/build/release etc... used in core, we get all that for free. I'm hesitant to diverge as this will increase the amount of work we need to do. Core has moved to Ivy, we may move to that at some point, but currently we're focused on adding functionality, fixing bugs -- not changing build. Patrick Anthony Urso wrote: Speaking of the contrib section, what is the status of ZOOKEEPER-103? Is it ready to be reevaluated now that 3.0 is out? Cheers, Anthony On Fri, Jan 9, 2009 at 11:58 AM, Mahadev Konar wrote: Hi Kevin, It would be great to have such high level interfaces. It could be something that you could contribute :) . We havent had the bandwidth to provide such interfaces for zookeeper. It would be great to have all such recipes as a part of contrib package of zookeeper. mahadev On 1/9/09 11:44 AM, "Kevin Burton" wrote: OK so it sounds from the group that there are still reasons to provide rope in ZK to enable algorithms like leader election. Couldn't ZK ship higher level interfaces for leader election, mutexes, semapores, queues, barriers, etc instead of pushing this on developers? Then the remaining APIs, configuration, event notification, and discovery, can be used on a simpler, rope free API. The rope is what's killing me now :) Kevin
Contrib section (nee Re: A modest proposal for simplifying zookeeper :)
Speaking of the contrib section, what is the status of ZOOKEEPER-103? Is it ready to be reevaluated now that 3.0 is out? Cheers, Anthony On Fri, Jan 9, 2009 at 11:58 AM, Mahadev Konar wrote: > Hi Kevin, > It would be great to have such high level interfaces. It could be > something that you could contribute :) . We havent had the bandwidth to > provide such interfaces for zookeeper. It would be great to have all such > recipes as a part of contrib package of zookeeper. > > mahadev > > On 1/9/09 11:44 AM, "Kevin Burton" wrote: > >> OK so it sounds from the group that there are still reasons to provide >> rope in ZK to enable algorithms like leader election. >> Couldn't ZK ship higher level interfaces for leader election, mutexes, >> semapores, queues, barriers, etc instead of pushing this on developers? >> >> Then the remaining APIs, configuration, event notification, and discovery, >> can be used on a simpler, rope free API. >> >> The rope is what's killing me now :) >> >> Kevin > >
Re: A modest proposal for simplifying zookeeper :)
Well if that were the direction, goal, I'd feel more comfortable about recommending ZK.. If a company were to implement some of these algorithms then I suspect they'd run into a race condition, etc with all that rope. For my part I'd be willing to contribute the NodeWatcher/NodeListener I wrote. Would be nice to have unit test for it that has all possible/unusual race conditions with ZK. Kevin On Fri, Jan 9, 2009 at 11:58 AM, Mahadev Konar wrote: > Hi Kevin, > It would be great to have such high level interfaces. It could be > something that you could contribute :) . We havent had the bandwidth to > provide such interfaces for zookeeper. It would be great to have all such > recipes as a part of contrib package of zookeeper. > > mahadev > > On 1/9/09 11:44 AM, "Kevin Burton" wrote: > > > OK so it sounds from the group that there are still reasons to > provide > > rope in ZK to enable algorithms like leader election. > > Couldn't ZK ship higher level interfaces for leader election, mutexes, > > semapores, queues, barriers, etc instead of pushing this on developers? > > > > Then the remaining APIs, configuration, event notification, and > discovery, > > can be used on a simpler, rope free API. > > > > The rope is what's killing me now :) > > > > Kevin > > -- Founder/CEO Spinn3r.com Location: San Francisco, CA AIM/YIM: sfburtonator Skype: burtonator Work: http://spinn3r.com
Re: A modest proposal for simplifying zookeeper :)
Hi Kevin, It would be great to have such high level interfaces. It could be something that you could contribute :) . We havent had the bandwidth to provide such interfaces for zookeeper. It would be great to have all such recipes as a part of contrib package of zookeeper. mahadev On 1/9/09 11:44 AM, "Kevin Burton" wrote: > OK so it sounds from the group that there are still reasons to provide > rope in ZK to enable algorithms like leader election. > Couldn't ZK ship higher level interfaces for leader election, mutexes, > semapores, queues, barriers, etc instead of pushing this on developers? > > Then the remaining APIs, configuration, event notification, and discovery, > can be used on a simpler, rope free API. > > The rope is what's killing me now :) > > Kevin
A modest proposal for simplifying zookeeper :)
OK so it sounds from the group that there are still reasons to provide rope in ZK to enable algorithms like leader election. Couldn't ZK ship higher level interfaces for leader election, mutexes, semapores, queues, barriers, etc instead of pushing this on developers? Then the remaining APIs, configuration, event notification, and discovery, can be used on a simpler, rope free API. The rope is what's killing me now :) Kevin -- Founder/CEO Spinn3r.com Location: San Francisco, CA AIM/YIM: sfburtonator Skype: burtonator Work: http://spinn3r.com
